Stack-based buffer overflow bug found in glibc

A popular open-source C library used by thousands of unix-like machines which defines the "system calls" is vulnerable to buffer-overflow attacks.

Securing the Internet of Things
Securing the Internet of Things

Researchers at Google have announced in a blog post that glibc, the open-source C library used by thousands of unix-like machines which defines the “system calls” is vulnerable to buffer-overflow attacks.

According to Google, the bug was found as an engineer noticed that its SSH client segfaulted every time it tried to connect to a specific host. The issue was then discovered to be in glibc and not in SSH.

The glibc DNS client is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack.

The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl.

The ideal situation here is that everyone using GlibC updates it - the versions of glibc since 2.9 are all affected. If this isn't possible however, Google has suggested the short term solution of limiting the response sizes accepted by the DNS resolver locally, and ensuring that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.

The scale of the problem is difficult to determine because it is unclear how many devices and systems make use of the glibc code, but hundreds of thousands of others could be, and so manufacturers are being urged to test their systems against Google's proof of concept.

Major systems such as Windows and OS X are unaffected, likewise Google Android and Apple iOS devices use a different library which is not vulnerable to this particular attack.

Paul Ducklin, senior technologist at Sophos said: “Fortunately, a lot of Internet of Things devices don't use glibc, because it is rather large. Instead, they often use more compact implementations of this core library, such as Google's bionic, used by Android, or uClibc. ("u" stands for the Greek letter mu, meaning "micro".)”

It appears that the bug was first reported to the team that maintains glibc in July last year, but it was flagged as low priority. The vulnerability is being compared to Shellshock, a bug discovered in 2014 which affected a huge range of computing devices.

According to Patrick Carey of Black Duck which offers solutions helping organisations to secure and manage open source software: "Vulnerabilities affecting widely used, foundational open source libraries like glibc are highly challenging for application development teams … The vulnerability has lain dormant in the code for years, apparently undetected by security testing tools.  And while Google has done a service in patching the bug, its report has also initiated a race between development teams and those who would try to exploit the vulnerability. 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. They must then patch those applications and make the updates available to their users. This can be a lengthy process, especially for applications that are installed on users' desktop or mobile devices, leaving them exposed for some time."

Jonathan Sander, VP of product strategy of Lieberman Software said: “This glibc bug is reminiscent of the OpenSSL vulnerability, Heartbleed. The most interesting bit about it may be the comment it makes about the open source community's ability to secure its code. The bug was introduced in 2008 and apparently had been in every version since that time. It was only found by a Google researcher by accident at this point, but when he reported it he found out the team that maintains glibc knew about it since July. While it's not uncommon for complex bugs like this to go undiscovered for a long time, it is a bigger question why it would be left there for seven months after discovery.”

Gavin Millard, technical director EMEA of Tenable Network Security said: "CVE-2015-7547 is a buffer overflow bug discovered in glibc that could, under certain circumstances lead to execution of code on a target system. Like GHOST, discovered 13 months ago that was also discovered in glibc, most Linux desktop and servers are affected. Although IoT devices and home routers generally use Linux, many use an alternate library so thankfully shouldn't be impacted.”

In an email to SC, Chris Eng, VP research, Veracode adds: “Though the potential impact of malicious code exploiting the glibc (CVE-2015-7547) vulnerability is great, exploiting it is not straightforward. An attacker may have to customise the exploit for each version of the library and for each operating system they wanted to go after.

"Like Heartbleed and Shellshock before it, the glibc vulnerability reinforces the reality that using components in the application development lifecycle introduces risk. ...our software is constructed like Legos, relying on components rather than coding. This is why it's important to have complete visibility into all of the components development team are using, as well as the versions being used to ensure they can quickly patch and/or update the component version when a new vulnerability is disclosed.”