Not since Stagefright have we had a vulnerability with the scale and reach of the glibc flaw disclosed on Tuesday.
“It’s pretty bad; you don’t get bugs of this magnitude too often,” said Dan Kaminsky, researcher, cofounder and chief scientist at White Ops. “The code path is widely exposed and available, and it yields remote code execution.”
The flaw affects most Linux servers, along with a number of web frameworks and services that make use of the open source GNU C library, including ssh, sudo, curl, PHP, Rails and others. Initial reports about the impact on Android were incorrect given that the OS uses the Bionic libc implementation and not glibc.
The harshness of the bug, a stack-based buffer overflow, rests in the fact that it lives in the glibc DNS client-side resolver, or libresolv library. Since DNS is a core network technology and most services rely on it, the horizontal scale of this bug is massive.
“An attack would first force a system to make specific DNS queries, using domain names controlled by the attacker. The attacker would then have to run custom-written DNS server software, which generates crafted responses that trigger the vulnerability,” Red Hat engineer Florian Weimer told Threatpost. It’s believed that the most direct exploitation vector would be a man-in-the-middle attack where an attacker would already be on the local network. “We do not know how difficult it is to exploit this over the Internet. We assume this is a possibility,” Weimer said, adding that he was not aware of any public exploits.
Kaminsky added that while man-in-the-middle attacks are problematic, it would be much worse if the flaw were exploitable through DNS caching-only servers.
“These servers do some scrubbing to make sure the name that comes back meets a bunch of rules. It dramatically reduces the exploitability of many flaws,” Kaminsky said. “The researchers are being cagey, but if they accidentally found the bug through the caching name server, in that case, it could just cause a server to look up an arbitrary name. This would be substantially worse if it went through the caching ecosystem; 99 percent of attack vectors go through that system.”
Carlos O’Donnell of Red Hat wouldn’t commit to that scenario yesterday in an advisory.
“A back of the envelope analysis shows that it should be possible to write correctly formed DNS responses with attacker controlled payloads that will penetrate a DNS cache hierarchy and therefore allow attackers to exploit machines behind such caches,” he wrote.
Adding to the severity of the issue is the fact that the vulnerability was introduced in glibc 2.9, which dates back to May 2008, giving attackers close to eight years to find and abuse the bug.
“We know as fact that multiple research groups found this and successfully coordinated work to fix it, which is very good,” Kaminsky said. “But we know its been around a decent amount of time, and we know it’s a golden vector that gets into all sorts of goodies. Likely, this has been discovered and exploited in the field.”
The bug, CVE-2015-7547, was discovered independently by researchers at Red Hat and Google who privately disclosed the issue to upstream glibc maintainers, Weimer told Threatpost. Coordination between the two camps began on Jan. 6, though the initial bug disclosure was made last July, according to an advisory on the glibc mailing list.
Weimer said that most Linux distributions that use glibc have patches available and a regular system upgrade followed by a reboot will address the issue. Source code patches for those who have their own software builds are also available.
“Most GNU/Linux distributions release glibc updates multiple times per year,” Weimer said. “These updates include not just security fixes, but also other bug fixes and performance enhancements. Fixes for glibc may be bundled with Linux kernel updates, making it beneficial to update both at the same time before a reboot.”
Google’s Fermin Serna said there are temporary mitigations that can be implemented until Linux machines can be patched, including limiting the size of a UDP or TCP response accepted by a DNS resolver, and to ensure that DNS queries are sent only to servers that limit the response size. Kaminsky, however, said that most network admins would be unlikely to implement those mitigations for fear of breaking other services.
“They’re still finding bugs of this magnitude accidentally,” Kaminsky said. “Using ambient bug discovery on core infrastructure is too slow. This was written in 2008 and it sat there year after year. We need to stop accidentally finding these bugs and start comprehensively finding them.”
Kamsinsky added that more comprehensive mitigations need to be deployed and enforced.
“We need to figure out how to reach a higher level of assurance on low-performance, high-risk code paths,” he said.
