Linux Glibc bug could leave millions of users at risk from vulnerable software and devices
Security researchers have discovered a potentially catastrophic flaw in one of the Internet’s core building blocks that leaves hundreds or thousands of apps and hardware devices vulnerable to attacks that can allow potential hackers to take control over them.
According to the researchers, the vulnerability exists since 2008 when it was introduced in GNU C Library. The GNU C Library is a open source code which is used to power thousands of apps, software and is used in most Linux distros. The bug also leaves home routers and other Internet of Things (IoT) devices vulnerable to attacks.
Ars Technica notes that a function known as getaddrinfo() that performs domain-name lookups contains a buffer overflow bug that allows attackers to remotely execute malicious code. It can be exploited when vulnerable devices or apps make queries to attacker-controlled domain names or domain name servers or when they’re exposed to man-in-the-middle attacks where the adversary has the ability to monitor and manipulate data passing between a vulnerable device and the open Internet. All versions of glibc after 2.9 are vulnerable.
The glibc dev team has released an update that patches the vulnerability. It has requested that any software or hardware that performs domain name lookups should install the patch as soon as possible.
However, due to the nature of the bug, it is extremely difficult to know how serious the problem is and how many devices could be affected by it.
“Many people are running around right now trying to work out if this is truly catastrophic or whether we have dodged a bullet,” said Prof Alan Woodward, a security expect from the University of Surrey.
Despite releasing a patch, as said above, the glibc bug could leave thousands of nomad devices such as cheap home routers vulnerable. Also some apps that were compiled with a vulnerable version of glibc will have to be recompiled with an updated version of the library, a process that will take time as users wait for fixes to become available from hardware manufacturers and app developers.
In a blog post explaining the discovery, Google’s team detailed how a flaw in some commonly-used code could be exploited in a way that allows remote access to a devices – be it a computer, internet router, or other connected piece of equipment.
The code can also be within many of the so-called “building blocks” of the web – programming languages such as PHP and Python are affected, as well as systems used when logging in to sites or accessing email.
Anyone who is in a position to update should do so as soon as possible. Google’s blog post continued:
Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. 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.
Meanwhile, Glibc maintainers provided the following additional mitigation details:
Mitigating factors for UDP include:
– A firewall that drops UDP DNS packets > 512 bytes.
– A local resolver (that drops non-compliant responses).
– Avoid dual A and AAAA queries (avoids buffer management error) e.g.
Do not use AF_UNSPEC.
– No use of `options edns0` in /etc/resolv.conf since EDNS0 allows
responses larger than 512 bytes and can lead to valid DNS responses
– No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both
lead to valid large EDNS0-based DNS responses that can overflow.
Mitigating factors for TCP include:
– Limit all replies to 1024 bytes.
Mitigations that don’t work:
– Setting `options single-request` does not change buffer management
and does not prevent the exploit.
– Setting `options single-request-reopen` does not change buffer
management and does not prevent the exploit.
– Disabling IPv6 does not disable AAAA queries. The use of AF_UNSPEC
unconditionally enables the dual query.
– The use of `sysctl -w net.ipv6.conf.all.disable_ipv6=1` will not
protect your system from the exploit.
– Blocking IPv6 at a local or intermediate resolver does not work to
prevent the exploit. The exploit payload can be delivered in A or
AAAA results, it is the parallel query that triggers the buffer
The vulnerability is being compared to Shellshock, a bug discovered in 2014 which affected a huge range of computing devices. Red Hat officials have more information here.