Critical Glibc flaw opens Linux distros, other software and devices to compromise
A critical bug has been found to open an unimaginable number of computers, networking and other connected devices to attacks that can result in complete system compromise.
Discovered independently by Google and Red Hat researchers, the bug resides in the GNU C Library (aka “glibc”), the open-source implementation of the C and C++ programming language libraries. Glibc is incorporated in practically every major Linux distribution, many embedded systems, devices like routers, many small-device projects, and so on. The flaw can be exploited to effect remote code execution.
“The glibc DNS client side resolver 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,” Google researchers explained.
The bug (CVE-2015-7547) has been patched, and the patch made available. For those who can’t implement it for the time being, there are possible mitigations.
“The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set,” Google researchers noted. Glibc maintainers also gave advice about mitigating factors and a list of mitigations that don’t work.
Google researchers say that exploitation of the flaw is not that straightforward, but that it is possible, and have offered a “non-weaponized Proof of Concept” that can be used by admins to check whether their systems are vulnerable.
It’s difficult to compile an exhaustive list of affected devices and software.
We know that Red Hat and Debian developers have already pushed out updated glibc packages that fix the flaw. We know that Windows or OS X are not vulnerable, and neither is Google’s Android (it uses an alternative library).
“Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though,” noted Google researchers.
The bug was introduced into the library back in 2008, and it’s a mystery how it wasn’t noticed at the time. Interestingly enough, the bug was flagged in July 2015, but it’s still unclear why it wasn’t fixed earlier. Who knows how many times it was discovered in the past, and its existence not shared with the developers.
“Many versions of Linux use glibc as a core component of the operating system. This means that applications can share the central copy of this programming library instead of all carrying around their own version,” noted Paul Ducklin, Senior Technologist at Sophos.
“The bad thing about this is that a bug in glibc therefore tends to affect almost every program on your system; the good news is that by patching the central copy, you magically ‘fix’ every application that depends upon it. In other words, as soon as your operating system distro has a patch, get it.”
“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,” he pointed out.
“However, finding out whether your IoT ‘things’ are affected isn’t easy – even if you know what to look for, you often can’t access the innards of the device. You pretty much have to ask the vendor.”
Brendan Rizzo, technical director EMEA at HPE Security – Data Security, says that once the full extent of this vulnerability is determined, administrators will quickly move into triage mode, addressing the problems that are most obvious and most under public scrutiny.
“Attackers, on the other hand, generally avoid the ‘front door’ and will be shifting their focus to secondary attack vectors,” he noted.
“Companies will need to shore up all possible attack vectors of this vulnerability. This can only happen once organisations have performed a thorough assessment to uncover everywhere they are using the vulnerable code in their applications.”