Google and Red Hat researchers released a patch for a critical remote code execution flaw in glibc 2.9 and later.
Researchers have discovered a critical vulnerability in the GNU C library, glibc, that could put modern Linux servers at risk for remote code execution attacks. API Web services and major Web frameworks like Rails, PHP, and Python are also affected.
The vulnerability (CVE 2015-7547), a stack-based buffer overflow in the getaddrinfo() function in the glibc DNS client-side resolver, has already been patched. Anyone using glibc 2.9 and later — since 2.9 was released in May 2008, that means pretty much anyone using glibc — should patch as soon as possible. Red Hat Enterprise Linux 5 has glibc 2.5, so it isn’t vulnerable, but Red Hat Enterprise Linux 6 (glibc 2.12), Red Hat Enterprise Linux 7 (glibc 2.17), Debian squeeze (glibc 2.11), Debian wheezy (glibc 2.13), and Debian jessie (glibc 2.19) are all affected.
“No, seriously, patch glibc today. This is bad,” Kenneth White, a security research and director of the Open Crypto Audit Project, wrote on Twitter.
The flaw was initially reported to the glibc project team by Robert Holiday of Ciena in July 2015. Carlos O’Donnell, a principal software engineer at Red Hat, and Florian Weimer, a member of the Red Hat Product Security Team, assessed the impact of the security hole and prepared the patch. Google researchers Fermin J. Serna and Kevin Stadmeyer found the vulnerability independently of the initial report and developed a proof-of-concept exploiting the flaw.
“We know of no known attacks that use this specific vulnerability,” O’Donnell said.
The getaddrinfo() function is typically used to resolve IP addresses, so in this case, attackers can use the vulnerability to gain control over applications and systems as they connect to a malicious DNS server. There are a number of ways to attack this vulnerability, including (but not limited to) ssh, sudo, and curl, Google researchers said.
“Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack,” Serna and Stadmeyer wrote in an advisory.
The vulnerability is triggered when the system receives from the DNS server an oversized UDP or TCP response, greater than 2048 bytes, followed by another response which overwrites the stack. One way to trigger the buffer management flaw requires the target system to attempt a DNS lookup for a domain controlled by the attacker. The first response it receives is 2048 bytes long, which fills the buffer entirely with no room left over. Since the buffer can’t be reused, a new buffer is created, but the bug causes the old buffer to be used along with the new, resulting in a buffer that is 65535 in size. The second response is flawed in a way that forces the system to retry the query. The third response contains 2048 bytes of valid response and the attack payload in the remaining 63487 bytes.
The flaw happens because when the query is restarted, it points to a buffer created with the wrong size, O’Donnell said. “There are other ways to trigger the buffer management flaw, but they require slightly more control over the timing of the responses and use poll timeout to carry out the exploit with just two responses from the attacker (as opposed to three),” O’Donnell said.
Red Hat researchers were able to control the execution of one free() call with the buffer overflow and gain control of the EIP register. While they did not try to exploit the vulnerability further, the single attempt showed that remote control execution was possible.
“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,” O’Donnell wrote on the glibc project mailing list.
The degree of exploitation depends on the countermeasures the system has in place against stack-based buffer overflows. Remote code execution is possible “but not straightforward,” because it requires bypassing ASLR, Google’s Serna said. Administrators and developers who cannot patch glibc right away should adopt temporary mitigations to protect against potential attacks. One option is to limit the response sizes accepted by the DNS resolver locally to 1024 bytes.
Be careful about the size limits, since systems using advanced features like DNSSEC need to be able to receive oversized UDP responses. DNSSEC requires EDNS0, a client feature that signals to servers that it can receive UDP responses larger than 512 bytes. Blocking large DNS responses can potentially break EDNS0. “DNS resolution may fail or will be significantly delayed,” warned SANS Institute’s Johannes B. Ullrich.
Administrators should make sure all systems on the network use a specific resolver and block outbound DNS unless it originates from the known resolver. Doing so limits exposure, and “is a good idea anyway,” Ullrich said.
While avoiding dual A and AAA queries may help mitigate the vulnerability, disabling IPv6 outright will not disable AAAA queries or prevent exploitation. Blocking IPv6 at a local or intermediate resolver does not work to prevent exploit because the exploit payload can still be delivered. “It is the parallel query that triggers the buffer management flaw,” O’Donnell wrote.
While the patch is available, the race is on as to who moves faster: attackers or defenders. “Now that the cat is out of the bag, dev teams need to quickly determine which of their applications are at risk: a difficult task given how deeply glibc integrates into applications,” said Black Duck Software’s Patrick Carey. The patching process can be a lengthy process, especially for mobile devices and other user-facing applications.
The glibc library is the GNU Project’s implementation of the standard C library and is widely used in GNU Linux and other systems using the Linux kernel. This is the second critical vulnerability in the library in recent months: researchers discovered the GHOST vulnerability (CVE 2015—235) in glibc just last year.