Slashdot Mirror
Red Hat, Google Disclose Severe Glibc DNS Vulnerability; Patched But Widespread
An anonymous reader writes: Today Google's online security team publicly disclosed a severe vulnerability in the Gnu C Library's DNS client. Due to the ubiquity of Glibc, this affects an astounding number of machines and software running on the internet, and raises questions about whether Glibc ought to still be the preferred C library when alternatives like musl are gaining maturity. As one example of the range of software affected, nearly every Bitcoin implementation is affected.
Reader msm1267 adds some information about the vulnerability, discovered independently by security researchers at Red Hat as well as at Google, which has since been patched: The flaw, CVE-2015-7547, is a stack-based buffer overflow in the glibc DNS client-side resolver that puts Linux machines at risk for remote code execution. The flaw is triggered when the getaddrinfo() library function is used, Google said today in its advisory. "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," Red Hat said in an advisory. It's likely that all Linux servers and web frameworks such as Rails, PHP and Python are affected, as well as Android apps running glibc.
If you are statically linked AND you do something that results in DNS resolution (like resolving a hostname to IP), then yea, you'd need a recompile. If you are dynamically linked than probably you will pull down a fixed library. Alternatively, they do have a patch. Also they have a workaround you can use if that's impractical, where you limit the DNS size response.
In the wild this will be nontrivial to exploit because you already choose your DNS servers with some care, and DNS servers are already a target (and therefore reasonably hardened) because of all the phat lewtz you can harvest if you point people to your fake address). So it's a serious vulnerability but not one that could instantly go wormy on us.
How does it happen that two people independently notice a bug? They both run the program, and it crashes because there's a bug. They're both running the same code, so they get the same crash. It's not immediately obvious that the crash has any security impact, and if so, how severe.
In the case of Red Hat and Google, both have teams who fix bugs in Linux, so whoever notices it files a bug report for the appropriate team. At Red Hat, when it's noticed that there are potential security implications, it's sent to Florian's team. Florian's team works carefully to fully understand it, look for related issues*, and work out the BEST way to fix it. They have a pile of bugs they're working at any given time.
Over at Google, the bug was found later, but the severity of the security implications were noticed sooner, so Google found the security issue WHILE Red Hat was working through their process.
* An example of Red Hat's "find and fix the whole issue, not just the obvious part", is shell shock. After the initial CVE for shell shock, several people proposed different ways of fixing it. Florian was one, he quickly worked on it and released a proposed patch. Over the next few days there were three MORE CVEs for shell shock, covering different variations on the same theme. Florian's initial patch covered all of them, including the ones that hadn't been fully characterized when he proposed it. His approach was approved by general consensus and that's what we all use today - partly because he put in the time and effort to fix the broader issue, not just the specific case that had been identified. This approach means that sometimes it takes Red Hat a while to release a fix, but when they do, it's the right fix.
Doesn't the operating system already have one?
Yeah it has one, the one in the C library.