The vulnerability Optionsbleed in Apache HTTP Server that can cause certain systems to leak potentially sensitive data in response to HTTP OPTIONS requests.
The freelance journalist and security researcher Hanno Böck discovered a vulnerability, dubbed ‘Optionsbleed’. in Apache HTTP Server (httpd) that can cause certain systems to leak potentially sensitive data in response to HTTP OPTIONS requests.
Böck was analyzing HTTP methods when he noticed that requests with the OPTIONS method, which is normally used by a client to ask a server which HTTP methods it supports, were returning apparently corrupted data via the “Allow” header instead of the list of supported HTTP methods (e.g. “Allow: GET, POST, OPTIONS, HEAD”). However, some of the responses to the researcher’s requests looked like this:
Below an example of the response obtained by Böck:
Allow: POST,OPTIONS,,HEAD,:09:44 GMT Allow: GET,HEAD,OPTIONS,,HEAD,,HEAD,,HEAD,, HEAD,,HEAD,,HEAD,,HEAD,POST,,HEAD,, HEAD,!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" Allow: GET,HEAD,OPTIONS,=write HTTP/1.0,HEAD,,HEAD,POST,,HEAD,TRACE
Apache leaked server memory due to a use-after-free bug tracked as CVE-2017-9798.
Respect other flaws “bleeding” memory contents like Heartbleed, the Optionsbleed vulnerability is less severe because in order to be exploited the targeted system needs to be configured in a certain way, and anyway the response doesn’t always contain other data.
Security firm Sophos published a detailed analysis of the vulnerability.
The expert tested the Optionsbleed flaw in the Alexa Top 1 Million websites and received corrupted Allow headers from only 466 of them.
With the support of the Apache developer Jacob Champion, Böck verified that the Optionsbleed vulnerability only affects specific configurations. Böck has released a proof-of-concept (PoC) script for Optionsbleed.
“Apache supports a configuration directive Limit that allows restricting access to certain HTTP methods to a specific user. And if one sets the Limit directive in an .htaccess file for an HTTP method that’s not globally registered in the server then the corruption happens. After that I was able to reproduce it myself. Setting a Limit directive for any invalid HTTP method in an .htaccess file caused a use after free error in the construction of the Allow header which was also detectable with Address Sanitizer. (However ASAN doesn’t work reliably due to the memory allocation abstraction done by APR.)” explained the researcher.
The researcher highlighted potential risks for shared hosting environments.
“The corruption is not limited to a single virtual host. One customer of a shared hosting provider could deliberately create an .htaccess file causing this corruption hoping to be able to extract secret data from other hosts on the same system,” Böck added.
The problem is not new, it was analyzed in a paper titled “Support for Various HTTP Methods on the Web” published back in May 2014, just a few weeks after the disclosure of the Heartbleed vulnerability.
The bad news for the Apache users is that the maintainers of the project could not provide an estimated date for the fix, for this reason, he decided to share its findings.
Development teams behind Linux distributions have also started releasing fixes for the Optionsbleed flaw.
[adrotate banner=”9″]
(Security Affairs – Optionsbleed, Apache server)
[adrotate banner=”12″]
