ADVISORY: OPTIONS method can leak Apache’s server memory

Nowaday, vulnerabilities are out: last week, we communicated about a remote command execute (RCE) which had been discovered in Apache Struts 2, and now, 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 happended 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 the client. Exploitation though “.htaccess” 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).

Are DenyAll products impacted by this disclosure ?

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 for DenyAll WAF and i-Suite, 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 in rWeb, 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.

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

Xavier Quoniam, Marketing Manager on Linkedin
Xavier Quoniam, Marketing Manager
Xavier is our Marketing Manager. He is passionate about disruptive technologies that transform how companies communicate. He brings us its passion, curiosity, and fresh ideas to promote DenyAll and Cloud Protector at its best.
Paste your AdWords Remarketing code here

By continuing to browse on our website, you agree to the use of Cookies for: (i) the operation and interactivity of our website, (ii) measuring the audience of our website and analyse your browsing. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.