[Hanno Böck] recently uncovered a vulnerability in Apache webserver, affecting Apache HTTP Server 2.2.x through 2.2.34 and 2.4.x through 2.4.27. This bug only affects Apache servers with a certain configuration in .htaccess
file. Dubbed Optionsbleed, this vulnerability is a use after free error in Apache HTTP that causes a corrupted Allow header to be replied by the webserver in response to HTTP OPTIONS requests. This can leak pieces of arbitrary memory from the server process that may contain sensitive information. The memory pieces change after multiple requests, so for a vulnerable host an arbitrary number of memory chunks can be leaked.
Unlike the famous Heartbleed bug in the past, Optionsbleed leaks only small chunks of memory and more importantly only affects a small number of hosts by default. Nevertheless, shared hosting environments that allow for .htaccess
file changes can be quite sensitive to it, as a rogue .htaccess
file from one user can potentially bleed info for the whole server. Scanning the Alexa Top 1 Million revealed 466 hosts with corrupted Allow headers, so it seems the impact is not huge so far.
The bug appears if a webmaster tries to use the “Limit” directive with an invalid HTTP method. We decided to test this behaviour with a simple .htaccess
file like this:
<Limit A> Allow from all </Limit> <Limit BB> Allow from all </Limit> <Limit CCC> Allow from all </Limit>
Soon enough, after a dozen of requests or so, the webserver replies clearly started to look very suspicious:
$ curl -sI -X OPTIONS http://10.9.0.1/index.html HTTP/1.1 200 OK Date: Tue, 19 Sep 2017 15:03:59 GMT Server: Apache/2.4.7 Allow: GET,HEAD,,allow,HEAD,,allow,HEAD,POST,OPTIONS,8���,HEAD,8����,HEAD,dex.html,HEAD, ���,HEAD, ����,HEAD,all,HEAD,,HEAD Content-Length: 0 Content-Type: text/html
Apache web server users should check existing configuration files and update. Most distributions should have updated packages by now or very soon. A patch for Apache version 2.4 can be found here and for Apache 2.2 is available here. Webserver administrators of shared hosting environments, should try to update as soon as possible, as the greater risk is really in these scenarios, where one user can potentially affect everyone else.
Solution, make all the commands exist and point the ones you don’t use to nothing.
Solution, make access sporadic and frequently change domain name.
Solution, make a standard to standardize all standards and apply that standard to the Apache project, primarily the standards for Apache configuration and options
Solution, embed server in concrete and lower it into the Mariana trench.
If you modify the .htaccess file for testing, an error 500 occurs.
How did you apply it?
I had no problem with the example above. I did encounter 500 replies when I forgot to close one limit tag… Maybe bad syntax in your .htaccess file?
“Apache web server users should check existing configuration files and update. Most distributions should have updated packages by now or very soon.”
Yeah, tell that to Equifax…
Would AWS offer such a patch?