Emergency workarounds for Oracle’s zero-day vulnerability

Recently an exploit has become publicly available which may impact the availability, confidentiality or integrity of WebLogic Server applications which use the Apache web server configured with the WebLogic plug-in for Apache. This vulnerability may be remotely exploitable without authentication, i.e. it may be exploited over a network without the need for a username and password.

The following versions of WebLogic Server and WebLogic Express are affected by this vulnerability:

  • WebLogic Server 10.0 released through Maintenance Pack 1, on all platforms
  • WebLogic Server 9.2 released through Maintenance Pack 3, on all platforms
  • WebLogic Server 9.1 on all platforms
  • WebLogic Server 9.0 on all platforms
  • WebLogic Server 8.1 released through Service Pack 6, on all platforms
  • WebLogic Server 7.0 released through Service Pack 7 on all platforms
  • WebLogic Server 6.1 released through Service Pack 7 on all platforms

In the security note related to this issue, Oracle provides two workarounds for this vulnerability, which they believe will provide protection against this vulnerability.

Apache LimitRequestLine Parameter

It is possible to configure Apache and avert this vulnerability by rejecting certain invalid requests. To do so, add the following parameter to the httpd.conf file and restart Apache:

LimitRequestLine 4000
See: Apache LimitRequestLine documentation for more information

Note: This parameter limits the maximum URL length to less than 4000 bytes.

Apache mod_security Module

Oracle believes that the workaround using the LimitRequestLine parameter will provide a workaround for WebLogic users that do not require URLs that exceed 4,000 bytes. If there are cases where the use of the LimitRequestLine parameter is not an option, users may also consider use of mod_security in Apache Web Server environments.

This is available in open source to address the vulnerability. The mod_security module need only be installed and enabled in order to provide a workaround for this vulnerability. Oracle recommends evaluation in customer environments prior to usage in production.

Oracle strongly recommends that you backup and comprehensively test the stability of your system upon application of any patch or workaround prior to deleting any of the original file(s) that are replaced by a patch or workaround.




Share this