A huge amount of Linux software can be hijacked by hackers from the other side of the internet, thanks to a serious vulnerability in the GNU C Library (glibc).

Simply clicking on a link or connecting to a server can lead to remote code execution, allowing scumbags to steal passwords, spy on users, attempt to seize control of computers, and so on. Any software that connects to things on a network or the internet, and uses glibc, is at risk.

The glibc library is a vital component in the vast majority of Linux distributions, meaning the security cockup is widespread in the open-source world.

The flaw, discovered separately by researchers at Google and Red Hat, is a stack-based buffer-overflow bug in glibc's DNS resolver – which is used to translate human-readable domain names, such as theregister.com, into a network IP address.

It is possible for a malicious DNS server to return too much information to a lookup request, and exploit the glibc flaw to flood the program's memory with code. This code can compromise the application, or try to take over the whole system.

A miscreant could create, say, evildomain.com, with malicious DNS name servers that exploit the aforementioned bug. Imagine getting an email with a link to evildomain.com, then clicking on that link. Your message client or web browser could attempt to lookup evildomain.com, and eventually get a buffer-busting response from the malicious name server.

The domain name could be injected into server log files, which when resolved will trigger remote code execution. An SSH client connecting to a server could also be compromised. Alternatively, a man-in-the-middle attacker on your network could tamper with DNS replies on-the-fly to inject payloads of malicious code.

There are all sorts of ways to exploit this bug (CVE-2015-7547), which is present all versions of glibc since version 2.9 that was released in May 2008. It's possibly in older versions, too.

Where glibc went wrong

"glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query. Later on, at send_dg() and send_vc() , if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated," Google's security team reported on Monday.

"Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow."

The Googlers warn that the overflow can be exploited when firing up sudo, curl, and other tools. A patch has been drafted to fix the programming blunder, and it should be landing on a Linux distribution near you very soon – so get ready to update your software.

Mitigations

The critical defect lies in resolv/res_send.c , and is triggered when the widely used getaddrinfo() function call is used.

The situation could be a lot worse: an attacker must bypass several operating system security mechanisms – such as ASLR and non-executable stack protection – to achieve successful remote code execution. Firewalls may also filter out dodgy DNS replies.

"A back of the envelope analysis shows that 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," said Carlos O'Donell, a Red Hat engineer.

You can mitigate now against assaults exploiting the CVE-2015-7547 flaw by limiting all TCP DNS replies to 1024 bytes, and dropping UDP DNS packets larger than 512 bytes.

The vast use of glibc makes this a really bad one for anyone using Linux. Luckily, a lot of embedded Linux devices – such as home routers and various gadgets – will be spared because they tend to use the uclibc library as it's more lightweight than hefty glibc.

Bug first spotted nearly a year ago

Intriguingly, this bug was reported in July last year but it was unclear if anything was done about it. The programming misstep was labeled "P2 normal," suggesting it was not being treated as a super high priority.

When Google's security engineers stumbled across the bug, they found that Red Hat's Florian Weimer and O’Donell were already on the case, and the group was able to work together to fix the source code.

It appears Weimer and O’Donell – both glibc maintainers – were investigating the flaw in private, away from the public bug trackers, due to the sensitivity of the issue.

The race is now on to get patching completed before the scummier end of the internet gets up to speed with the bug. Google bod Fermin Serna has published proof-of-concept code to demonstrate exploitation of the flaw. ®