Details on the GNU libc vulnerability

Details on the GNU libc vulnerability

on Feb 29, 16 • by Andrew Pomponio • with No Comments

Earlier in February, it was discovered that the getaddrinfo() function in all versions of glibc from 2.9 and up were vulnerable to a buffer overflow attack (CVE-2015-7547). Learn more...

Home » Open Source » Details on the GNU libc vulnerability

The business world relies heavily on the Linux operating system in a number of capacities, from a security standpoint to information processing and even to operations as simple hardware control software. Part of what makes Linux work is a particular library called the GNU C Library. Developed in 1987, this library, called glibc for short, gave Linux a functional C and C++ library to use. It eventually replaced the Linux libc library as it boasted better functionality.

Earlier in February of this year, it was discovered that the getaddrinfo() function in all versions of glibc from 2.9 and up were vulnerable to a buffer overflow attack (CVE-2015-7547). A flaw during domain name requests allowed for a buffer overflow which allows attackers to execute malicious code remotely. If the traffic was not encrypted or used weak ciphers, the function was also vulnerable to man in the middle attacks. The function is present in Linux and other software that uses the GNU C Library for domain name lookups using the getaddrinfo() function.

While some users are able to just patch glibc on their Linux environment, any applications that were compiled with a vulnerable version of the glibc library will need to be re-compiled with the patched version (2.23). This process usually does not occur overnight and involves testing and planning, leaving the users of the software vulnerable until the fix is tested and implemented. In terms of business impact, this solution may be a long term and costly implementation. For further perspective on the reach of this bug, consider that utilities in Linux such as sudo, curl, and secure shell are all compiled with glibc. Even something as simple as the wget utility is vulnerable according to a proof-of-concept posting by security researcher Kenn White.

Anatomy of attack

To perform the attack, an attacker runs a malicious DNS server of their own and impersonates a valid DNS server responding to client requests. When a client makes a call out looking to resolve a host name to an IP address, the malicious DNS server intercepts the call and responds back pretending to be the valid server. By masquerading as the DNS server the user was trying to reach, it can then route the request to any destination it wants, giving the attacker the capability to direct you to their own server.

When glibc is waiting for a response from the DNS server during a query, it has a total of 2048 bytes of stack memory available for these responses. If it receives a response that’s larger than 2048 bytes, a new buffer is allocated from the heap and all the information is updated. A mismatch of information can occur between the stack buffer and the new heap allocation if the right conditions are met. The stack buffer will overflow trying to store the DNS response because it’s larger than the stack buffer and heap buffer that were allocated. The stack ends up with two outstanding requests at the same time, one for IPv4 and another for IPv6. When both these requests come in simultaneously, the stack overflow occurs.

Flaws in DNS that contribute to this vulnerability lie with its ability to operate on both TCP and UDP ports with the ability to upgrade from one to the other. Errors in resolution and retry efforts are handled by the caching resolver and not the stub (glibc), which means errors and retries are not likely to reach glibc. DNS requests traditionally have a 512 byte limit. Since glibc doesn’t issue an EDNS0 request that would declare a larger buffer size, it was believed that the data would not be able to survive in memory as valid DNS cache data to create a failed state for the stack overflow to occur. An attacker can bypass this failsafe by setting the TCP “Truncation” bit to force DNS to use TCP instead of UDP which can then traverse caching. Once traffic has passed the layer of cache inspection, the code is in the network and viewed as valid traffic. As of right now, no actual exploits of this vulnerability have been achieved, but the theoretical impact is of devastating size in terms of users and organizations affected.

Check yourself

Though vulnerabilities exist for the Linux operating system, the list is rather short of the ones that can actually execute remote code at the sudo or administrator level such as the one discussed here. To make matters worse, the code that contains this vulnerability has been in use since May of 2008, meaning that there has been nearly 8 years of software developers compiling vulnerable versions of glibc into their applications. If you have an application that was developed between May of 2008 and now that uses glibc, it’s imperative that you check and see about updating the library and possibly re-compiling the affected software.

OpenLogic customers received a special security announcement about this flaw shortly after it went public. Sign up for the free edition of OpenUpdate to learn about OSS releases and security updates as they happen. Or contact us, we’re always available for consulting if you need help addressing this vulnerability in your own applications.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top