A remote code execution vulnerability in glibc [LWN.net]

The Google Online Security Blog discloses a security issue in the GNU C library; a fix, workarounds, and a proof-of-concept exploit are all provided. "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."

See also: the glibc advisory for this issue.

to post comments

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 16:16 UTC (Tue) by ledow (guest, #11753) [Link] (9 responses)

"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."

Well... why the hell not? If you specifically disable IPv6, why are AAAA entries looked up or attempted to be parsed, ever? Surely this is a performance and (now) a security issue? That just seems to me to be the most stupid overriding of a specific and explicit sysctl ever.

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 16:38 UTC (Tue) by miquels (guest, #59247) [Link]

Sysctl changes kernel behaviour, not userland/library behaviour. This bug is in glibc, not the kernel. Besides, even v4-only servers/applications might want to look up an AAAA record. It's just another record in the DNS, like A, MX, TXT etc.

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 16:39 UTC (Tue) by cortana (subscriber, #24596) [Link]

sysctls configure kernel behaviour, do they not? I'm pretty happy that various clients of the kernel don't overload them with their own interpretations of what they should mean.

If glibc should interpret that sysctl and disable its resolver's lookup of AAAA records, then why shouldn't Java also use it to set the default value of the java.net.preferIPv4Stack system property, and so on... I think that way, madness lies!

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 17:03 UTC (Tue) by MarcB (subscriber, #101804) [Link]

I am doing countless IPv6 queries per day - from machines that have no IPv6 addresses and not even Internet access.

DNS is just a database. And I certainly would not want to miss records from it, just because of my network configuration. (Arguably one could use a separate resolver from the system resolver for such purposes, but that would be a fundamental change and break countless pieces of software)

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 17:09 UTC (Tue) by nye (guest, #51576) [Link] (1 responses)

>Well... why the hell not? If you specifically disable IPv6, why are AAAA entries looked up or attempted to be parsed, ever?

Because you used AF_UNSPEC, which specifically asks it do do that:
>The value AF_UNSPEC indicates that getaddrinfo() should return socket addresses for any address family (either IPv4 or IPv6, for example) that can be used with node and service

There are plenty of times that you might want to do these lookups even though you don't currently have IPv6 connectivity yourself.

Arguably there are a lot of places that perhaps shouldn't actually be unconditionally using AF_UNSPEC at all, but there doesn't appear to be an AF_DOTHERIGHTTHING and it's awkward to bake in a check for IPv6 connectivity into your app so as to use AF_INET or AF_INET6 as appropriate (plus that seems like a layering violation to me), so it's hard to blame application developers.

In other words, the bug is in the API.

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 20:30 UTC (Tue) by fw (subscriber, #26023) [Link]

There is AI_ADDRCONFIG, which is supposed to optimize behavior in this area, but there are multiple conflicting requirements, and it's difficult to come up with a generally applicable approach.

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 20:28 UTC (Tue) by fw (subscriber, #26023) [Link] (2 responses)

I think the general idea was that if you make enough AAAA queries, people would fix more quickly broken DNS infrastructure which did not cope well with AAAA queries or responses. I'm not sure if that's still a reasonable approach today. The dual-lookup acceleration in glibc has also caused a lot of pain by itself, even before today's update.

There is also a distinct lack of kernel APIs to determine whether the system supports IPv6 or not. In fact, for a certain class of systems, it is cheaper to avoid making the determination until you have received AAAA records from the DNS, and skip it altogether if you do not receive such records.

A remote code execution vulnerability in glibc

Posted Feb 17, 2016 14:58 UTC (Wed) by jengelh (subscriber, #33263) [Link] (1 responses)

>There is also a distinct lack of kernel APIs to determine whether the system supports IPv6 or not.

There is an API: rtnetlink's RTM_GETROUTE.

A remote code execution vulnerability in glibc

Posted Feb 17, 2016 15:15 UTC (Wed) by fw (subscriber, #26023) [Link]

This approach doesn't really work for systems with large routing tables (or many configured IP aliases).

A remote code execution vulnerability in glibc

Posted Feb 17, 2016 10:55 UTC (Wed) by copsewood (subscriber, #199) [Link]

AAAA responses resulting from lookups from an IPV4 client should generally be passed back to the client by the DNS resolver, unless the latter knows that the particular client needs to go through some kind of gateway to access an IPV6 only server. In that situation the client can be passed an A record for the IPV4/IPV6 gateway which can proxy the (presumably HTTP) request. If it's a HTTPS request, then unless the gateway can sign a certificate for the website with a key the client trusts, the response will be indistinguishable from a MITM attack.

A remote code execution vulnerability in glibc

Posted Feb 16, 2016 19:46 UTC (Tue) by alkadim (guest, #104623) [Link] (2 responses)

Critical vulnerability doesn't include marketing campaign. This is news.

A remote code execution vulnerability in glibc

Posted Feb 17, 2016 14:36 UTC (Wed) by ceplm (subscriber, #41334) [Link] (1 responses)

??? What are you talking about?

A remote code execution vulnerability in glibc

Posted Feb 17, 2016 15:08 UTC (Wed) by drag (guest, #31333) [Link]

It has been popular lately to create a marketing label for sever vulnerabilities in order to promote one's business. A good example of this is the 'HeartBleed bug'. It was successful enough that it has it's own wikipedia page.

A remote code execution vulnerability in glibc

Posted Feb 17, 2016 2:24 UTC (Wed) by flussence (guest, #85566) [Link] (1 responses)

How much should I panic if all my DNS traffic goes via local BIND9/unbound?

A remote code execution vulnerability in glibc

Posted Feb 17, 2016 8:59 UTC (Wed) by sourcejedi (guest, #45153) [Link]

It's listed as a mitigating factor for UDP (assuming your daemon drops invalid responses), but for TCP you need different mitigations (and I think switching to TCP is trivial to trigger).

However "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."

I think the real reason to calibrate your panic is that we don't _know_ of anyone using this yet, and Google didn't publish a weaponized exploit (defeating ASLR etc).