Google, with the help of Red Hat, recently discovered a buffer overflow problem in the GNU C Library (commonly referred to as glibc), naming it CVE-2015-7547. The issue affects all versions of glibc since 2.9, so taking the time to update and mitigate the problem is critical. Furthermore, the vulnerability can affect any program operating under Linux, which uses this library for many of its core functions.

What’s the Problem?

As reported, the glibc Domain Name System (DNS) client-side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used; software utilizing this function can be potentially exploited through attacker-controlled domain names and DNS servers. An attacker that is able to insert a false address can subvert the normal DNS system and fool the app into accessing a Web resource it had no intention of visiting.

“Overflowing bytes are entirely under the control of the attacker and are the result of a crafted DNS response,” according to Carlos O’Donnell of Red Hat. “A back-of-the-envelope analysis shows 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.”

What does this mean? All Linux servers and Web frameworks, such as Rails, PHP and Python, would be at risk to have this buffer overflow affect their execution (by misdirecting the URLs in their API calls, for example) as well as any Android apps running glibc.

Any type of Linux-based app that makes a domain name call as part of its logic flow would also be affected. The affected application would only have to query the attacker-controlled domain names or servers, and the false responses the app could receive would impair them in any way the attacker wished.

Additionally, a man-in-the-middle (MitM) attack could be mounted. This exploit would allow the attacker to manipulate data passing from an app to the Internet by first making an app’s output send to their domain and resending it from there.

The Buffer Overflow Mechanism

The vulnerability relies on an oversized User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) response. If the response is larger than 2048 bytes, a new buffer will be allocated from the heap and the buffer pointer, new buffer size and response size are updated.

If the response is immediately followed by another response, a mismatch between the stack buffer and the new heap allocation can overwrite the stack. This leads to the stack-based buffer overflow because the DNS response is larger than the stack buffer used to originally store it even though a heap buffer had been allocated.

O’Donnell also said they had performed proof-of-concept tests on an exploit. “Local testing shows we have been able to control at least the execution of one free() call with the buffer overflow and gained control of EIP. Further exploitation was not attempted, only this single attempt to show that it is very likely that execution control can be gained without much more effort.”

Time to Patch and Mitigate

While patching is the best course of action, there might be mitigation strategies, as well.

“Our suggested mitigation is to limit the response (i.e., via Dnsmasq or similar programs) sizes accepted by the DNS resolver locally to ensure that DNS queries are sent only to DNS servers, which limit the response size for UDP responses with the truncation bit set,” explained Google researcher Fermin J. Serna.

In simpler terms, keep the buffer from overflowing by manually limiting its size, which prevents it from causing a request for more buffer memory. This way, no mismatch will occur, and no overflow ensues.

In any case, now that the flaw is widely known, an immediate response is necessary from system administrators to prevent exploiters from using it.