Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

What's new?

An information disclosure has been discovered in Apache HTTP Server. By sending HTTP requests using the "OPTIONS" method, the server can respond with an "Allow" header containing arbitrary chunks of memory.

This memory leak can only appended when the Apache Server use a set of authorizations through the <Limit> directive in .htaccess files with an "AllowOverride Limit" in the httpd.conf.

Details of the vulnerability

Apache httpd allows remote attackers to read arbitrary data from process memory if the <Limit> directive can be set in an user's .htaccess file (user as per shared hosting environments), and if httpd.conf has relaxed (mis)configurations, aka Optionsbleed.

This affects the Apache HTTP Server through 2.2.x through 2.2.34 and 2.4.x through 2.4.27. The attacker sends an unauthenticated OPTIONS HTTP request when attempting to read arbitrary data.

This is a use-after-recycle/free issue and thus secret data may be disclosed (though binary data would be blocked in latests 2.2.x and 2.4.x versions); the specific data depends on many factors including configuration, and unlikely to be controllable by a remote userclient. Exploitation in .htaccess files can be blocked with a patch to the ap_limit_section function in server/core.c, or by removing the token "Limit" (not present by default) from the "AllowOverride" directive in the main configuration file (httpd.conf, not writable by users).

Sources:

DenyAll Statement

DenyAll Products are not impacted as we do not use the <Limit> directive in our Reverse Proxy configurations.

As the vulnerability can be exploited using "OPTIONS" method in HTTP requests, a rule blocking all requests containing this method is all you need to mitigate exploits.

If your Apache backends are vulnerable, we recommend to apply the following rule:

DenyAll WAF and i-Suite products

As you may prefer, the rule can be applied in the Workflow or in an ICX configuration.

In the Workflow:

Add a Decision node in the Workflow to block the "OPTIONS" method.

In the ICX Configuration:

Add a negative rule in the ICX Configuration to block the "OPTIONS" method.


rWeb product

If you are using the default configuration of the HTTP Requests policy, only standard methods are allowed (GET, HEAD and POST). "OPTIONS" method will be blocked by default.

If not, we recommend to add a Blacklist custom rule to block the "OPTIONS" method.

Code Block
titlePattern for custom rule
^OPTIONS

 

For any further details, we invite you to contact the DenyAll Support Team.

Table of Contents