Security

The Glibc DNS resolution vulnerability

While the recently disclosed GNU C library (Glibc) DNS bug (CVE-2015-7547) is quite serious, one of the interesting aspects is that the real scope of the problem is not yet known. The ability to exploit this bog-standard buffer overflow is dependent on a number of other factors, so there are no known vectors for widespread code execution—publicly known, anyway. There are certainly millions of vulnerable systems out there, many of which are not likely to ever be patched, but it is truly unclear if that will lead to large numbers of compromised systems.

There are a number of obstacles in the way of an attacker wishing to exploit this bug. First off, a client application must call getaddrinfo() to resolve a domain name and use the AF_UNSPEC address family. That family indicates that either an IPv4 or IPv6 address is acceptable, which is the normal way that getaddrinfo() is called these days. Glibc then does two parallel queries for the A and AAAA records for the domain. It is the buffer handling in this parallel query step where things go awry.

Many systems are not configured to query a local caching nameserver; instead Glibc will make a query to the remote nameserver that was configured (or auto-configured by DHCP or the like) for the system. That means these two queries leave the system and, crucially, replies are received. Typically, DNS replies are short, but they can be as large as 64KB. Glibc allocates 2KB bytes on the stack for the reply, but it has provisions to increase that by allocating a heap buffer for replies that are larger. Unfortunately, if the query needs to be retried, the stack buffer gets used instead of the larger, newly allocated buffer, so roughly 62KB of attacker-controlled data can be written to the stack.

There are still more requirements to make all of this happen, though. Normally, UDP is used to do the query, which is typically limited to 512-byte replies, but a man-in-the-middle (MITM) attacker could send more data. But any server could set the "truncation bit" in the reply to cause the client to switch to TCP for its query. Causing the client to retry is evidently tricky, but can be done. The net result can be as bad as a bunch of attacker data on the stack, but even that may be difficult to turn into code execution due to address-space layout randomization (ASLR) and other defensive measures.

Ostensibly it would seem that an attacker could simply set up a DNS server for their domain that would send malicious responses (while causing retries), then "force" clients into looking up this compromised domain. But there are complications; most notably any caching resolvers between the attacker and victim will reject most or all of the malicious responses because they aren't well-formed. It is unclear, however, whether cache-surviving, malicious responses can be constructed.

In a detailed advisory, Glibc developer Carlos O'Donell of Red Hat indicated that the possibility exists:

Dan Kaminsky followed up on that in his own detailed analysis:

But Kaminsky goes on to posit that "some networks are going to be vulnerable to some cache traversal attacks sometimes", under the theory that attacks only get better over time. The emphasis on the cache is important. An MITM attacker does not need the malicious responses to reside in intermediary caching resolvers (and an MITM can do plenty of other malicious things), but others who might want to exploit this flaw do need that. If a way is found to get these malicious responses into caches, CVE-2015-7547 gets a whole lot worse.

The scope of programs affected by the vulnerability is rather surprising as well. As Kaminsky and others have noted, the problem affects many different programs, from sudo and httpd to gpg and ssh—and beyond. Languages like Python, Haskell, JavaScript, and others are also affected. Some of these "memory-safe" languages protect against buffer overflows in programs written in the language, but the runtimes for those languages use Glibc, so flaws at that level can still affect them. And plenty of programs look up domain names for a variety of reasons. As Kaminsky put it:

Clearly the best "mitigation" is to update affected systems, but that may not be possible in many cases. There are an enormous number of Glibc-using devices out there (e.g. some home routers) that rarely, if ever, get updates. Even if updates are released, getting them into the hands of users and onto the devices is decidedly non-trivial. That has some looking for other types of mitigation.

One that is often mentioned is limiting the size of DNS replies. If no reply is large enough to tickle the bug, then devices running the old code won't be affected. That still doesn't solve the MITM problem, but Kaminsky also argued that length-limiting will have other hard-to-diagnose effects, so it should be avoided. There is a reason that DNS has been engineered to allow for larger responses, so it is effectively too late to put that cat back in the bag.

Using a local caching resolver, rather than requiring Glibc to query the network, will also help in environments where that is possible. If cache-traversing responses eventually surface, they can be handled at that level. Both local and remote caching servers can be changed as we learn more over time. Kaminsky described it this way:

Some devices, Android devices in particular, use different C libraries, which are presumably not vulnerable to this particular flaw. There are undoubtedly other vulnerabilities in those, with unknown effects and scope—at least publicly. The bug in Glibc has existed for almost eight years (it was introduced in Glibc 2.9 in May 2008); it is hard to guess what else lurks there—or elsewhere.

It is refreshing to see a security vulnerability disclosed without a name, logo, animated GIF, and hype-ridden web page touting it. Instead we have the disclosure announcements along with some sober analysis of what it all might mean. That used to be the norm and, while it may be a little awkward to use "CVE-2015-7547" rather than some catchy name, it is a welcome change from the hoopla surrounding Heartbleed, GHOST, and others.

Comments (3 posted)

Security quotes of the week

Comments (28 posted)

Kaminsky: A Skeleton Key of Unknown Strength

Comments (5 posted)

chromium: code execution

Comments (none posted)

chromium: code execution

Comments (none posted)

didiwiki: unintended access

Comments (none posted)

ffmpeg: denial of service

Comments (none posted)

GraphicsMagick: out-of-bounds read flaw

Comments (none posted)

hamster-time-tracker: two denial of service flaws

Comments (none posted)

kernel: privilege escalation

Comments (none posted)

libssh: insecure ssh sessions

Comments (none posted)

libssh2: insecure ssh sessions

Comments (none posted)

libxmp: multiple vulnerabilities

Comments (none posted)

mariadb: multiple vulnerabilities

Comments (none posted)

ntp: three vulnerabilities

Comments (none posted)

obs-service-download_files: code injection

Comments (none posted)

php-horde-horde: cross-site scripting

Comments (none posted)

poco: SSL server spoofing

Comments (none posted)

websvn: cross-site scripting

Comments (none posted)