Risks Limited With Latest Apache Bug, Optionsbleed

The risks surrounding the latest Apache bug, called Optionsbleed, are limited given it can only be attacked under certain conditions. Apache, and many Linux distributions, have patched the flaw.

Servers running Apache software are susceptible to memory leaks that an attacker could theoretically piece together to learn secrets transmitted during a session. But the risk is most pressing only in shared hosting environments apparently, and only if the software is running a certain rare configuration.

Details of the bug, which has been called Optionsbleed given its similarity to Heartbleed and other vulnerabilities that leak memory, were disclosed yesterday by researcher Hanno Bock.

Bock pointed out in a report that an attacker could use the HTTP OPTIONS request method to exploit the vulnerability. The request returns an “Allow” header from a server running Apache with a list of supported methods. Servers running the misconfiguration also return what looks like corrupted data but instead were Apache configuration options.

Yann Ylavic, member of the Apache HTTP Server Project Management Committee, told Threatpost that the risk is limited and only a few bytes are leaked in affected configurations. There has been no indication sensitive data is disclosed, he said. The Apache Server Foundation has patched the vulnerability, as have a number of Linux distributions.

“The fix has been committed to our repository (‘upstream’) and will be in a new numbered release shortly,” Ylavic said. “Many of our users rely on a third party for their builds and maintenance, commonly Linux distribution vendors.”

Bock describes the issue as a use-after-free vulnerability, which Ylavic conceded is not difficult to reproduce on affected systems. Bock, however, said he was able to see only 466 hosts among the Alexa top 1 million sites returning corrupted Allow headers.

“The vast majority of systems are not running an affected configuration, and causing the configuration to be affected requires write access to the configuration. In some shared environments, one user with write access could cause the configuration to be affected without the knowledge of other users,” Ylavic said. “This can be mitigated already on unpatched systems, by setting some directives in the main configuration which is not writable by users (default configurations are not affected).”

Bock said he collaborated with Apache developer Jacob Champion who traced the issue to a configuration directive called Limit that allows restricting access to 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,” Bock wrote. “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.”

Jeff Williams, CTO and cofounder of Contrast Security, said attempts to exploit this flaw would be exceptionally noisy, and easy to identify and block.

“It looks like only small bits of this information are leaked. So it would be extremely difficult to get something useful,” Williams said. “Second, only 400-some servers are affected out of the top 1m. That dramatically reduces the attack options. They came up with a great name, OptionsBleed. And it’s theoretically interesting. But not much danger to you and me. Upgrade your server and get on with life.”

Ylavic said updates would be routine for most users.

“Medium and large users will generally have an architecture/procedure where maintenance can be rolled out without interruption,” he said. “The smallest of users, with a single server and no frontend load balancing, may take a brief but planned outage for any maintenance. The fix also consists in disallowing the misconfiguration, so some users may need to adapt their configuration (if ever they really needed it).”

Suggested articles