glibc security patch cve-2015-7547

ReaperX7 · 02-16-2016, 10:26 AM

https://sourceware.org/ml/libc-alpha.../msg00416.html

Not sure if this affects Slackware, but I figured I'd share anyways.

GazL · 02-16-2016, 11:11 AM

Yep, was just reading about this one. Patch hasn't made it into glibc.git yet as far as I can tell, but hopefully it won't be too long. Remote code injection via dns responses is definitely right up there in the "brown-trousers" category.

willysr · 02-16-2016, 06:14 PM

nice reading material: http://arstechnica.com/security/2016...es-vulnerable/

CTM · 02-16-2016, 07:04 PM

This is terrifying on a number of levels.

GazL · 02-16-2016, 07:12 PM

Quote:

Maintainers of glibc, as the open source library is called, released an update that patches the vulnerability

So where's the release? All I see is what looks like a patch submitted to the mailing list for review. Still no commits on git master or release/2.22/master for this. Am I missing something, or have ARS jumped the gun on announcing availability of an update.

CTM · 02-16-2016, 08:45 PM

Quote:

Originally Posted by GazL

So where's the release? All I see is what looks like a patch submitted to the mailing list for review. Still no commits on git master or release/2.22/master for this. Am I missing something, or have ARS jumped the gun on announcing availability of an update.

Ars confused a patch with a release: the developers don't think an immediate fix for this is important, given that the next stable release (which will address CVE-2015-7547) is planned to take place in a couple of days anyway.

edit: I hear that some vendors (Red Hat, Debian) have now released their own custom builds that include this patch.

willysr · 02-16-2016, 10:58 PM

it has been pushed to master
https://sourceware.org/ml/libc-alpha.../msg00425.html

GazL · 02-17-2016, 04:41 AM

Hold the phone!...

https://sourceware.org/ml/libc-alpha.../msg00416.html:

Quote:

The buffer overflow occurs in the function send_dg (UDP) and send_vc
(TCP) for the NSS module libnss_dns.so.2 when calling getaddrinfo with
AF_UNSPEC family and in some cases also with AF_INET6 before the fix in
commit 8479f23a (only use gethostbyname4_r if PF_UNSPEC).

The use of AF_UNSPEC triggers the low-level resolver code to send out
two parallel queries for A and AAAA. A mismanagement of the buffers used
for those queries could result in the response writing beyond the alloca
allocated buffer created by __res_nquery.

source/l/glibc/glibc-2.10-dns-no-gethostbyname4.diff.gz:

Code:

The gethostbyname4() lookup method is problematic since it fires out both
the A and AAAA DNS queries in parallel and over the same socket. This
should work in theory, but it turns out that many cheap DSL modems and
similar devices have buggy DNS servers - if the AAAA query arrives too
quickly after the A query, the server will generate only a single reply
with the A query id but returning an error for the AAAA query; we get
stuck waiting for the second reply.

For gethostbyname4() users affected, disabling IPv6 in the system might
work around the issue, unfortunately it only helps with applications
using AI_ADDRCONFIG (e.g. Firefox); some (notably e.g. Pidgin) neglect
to do that.

Real fix should be using separate ports for the A and AAAA queries.

--- resolv/Versions     2008-08-02 10:26:09.000000000 +0200
+++ resolv/Versions     2008-12-08 12:51:53.000000000 +0100
@@ -102,7 +102,7 @@ libnss_dns {
     _nss_dns_gethostbyname_r; _nss_dns_getnetbyaddr_r;
     _nss_dns_getnetbyname_r; _nss_dns_getcanonname_r;
     _nss_dns_gethostbyaddr2_r;
-    _nss_dns_gethostbyname4_r;
+#    _nss_dns_gethostbyname4_r;
   }
 }

Am I right in thinking that our patch is disabling these troublesome parallel queries anyway?

edit: To answer my own question; No, I don't think it is. It might mitigate for that second case they mentioned, but I think getaddrinfo() is still a concern. Though I freely admit all this library versioning stuff is a little over my head. Still, interesting to note the comments in that 8 year old patch and how this parallel lookup issue has come back to bite us.

edit2: Actually, strike that. I'm still not sure one way or the other.

hitest · 02-17-2016, 10:35 AM

Quote:

Originally Posted by ReaperX7

https://sourceware.org/ml/libc-alpha.../msg00416.html

Not sure if this affects Slackware, but I figured I'd share anyways.

Thanks about the heads-up, mate. Yes. I just read about that on the interwebz.

Altiris · 02-17-2016, 05:16 PM

So, will a patch be issued for Slackware? Or is it somehow not vulnerable? To my knowledge all glibc versions from a certain release and up are vulnerable .

volkerdi · 02-17-2016, 06:11 PM

Quote:

Originally Posted by Altiris

So, will a patch be issued for Slackware? Or is it somehow not vulnerable? To my knowledge all glibc versions from a certain release and up are vulnerable .

While I'm still investigating this, it's looking like we're somehow not vulnerable because of the patch mentioned by GazL. The proof of concept exploit does not work on any version of Slackware unless that patch (glibc-2.10-dns-no-gethostbyname4.diff.gz) is removed and glibc is recompiled. The patch came from openSUSE long ago, and was also used by Debian at one time, but we seem to be the only ones who still apply it. I've had two requests in email to remove the patch since glibc had supposedly fixed the issue that prompted it, but left it in place anyway. Maybe luck, maybe slack.

I do have patches for CVE-2015-7547 that I'll apply to -current anyway, although the exploit doesn't work there either. I attempted a few backports and have a finished one for 14.1, but the code in question has been a moving target over the years so if we got lucky and aren't vulnerable I'd say it's safer to issue no patches for stable versions.

Here's the PoC exploit code for anyone who is interested. You need to run the Python "nameserver" and point resolv.conf at it. Then the client test (or almost anything else that does a DNS lookup via glibc) should segfault.

https://github.com/fjserna/CVE-2015-7547

Further testing is appreciated.

haary · 02-18-2016, 03:26 AM

Confirmed: PoC does not work with 14.1 and -current (32 bit). It worked with an unpatched Debian 7 and CentOS 6.

GazL · 02-18-2016, 05:20 AM

While I could see early on that we weren't exporting the symbol for the function necessary to exploit this vulnerability it took me a while to figure out how all this was working (glibc seems to be a bit of a maze of twisty tunnels all alike!

) which is why I may have seemed a little uncertain in my posting above: basically, I was!

Turns out that the posix version of getaddrinfo.c essentially does this:

Code:

fct4 = __nss_lookup_function (nip, "gethostbyname4_r");
if (fct4 != NULL)
 // stuff to use gethostbyname4_r
else
 // stuff to use gethostbyname3_r

So, mystery solved.

IMO Pat is right to patch current as the underlying overflows are still present and alternative vectors for exploiting them might show up in the future, but Pat's "slackness" with regard to removing the dns patch does seem to have resulted in us dodging a pretty nasty bullet!

Three cheers for His Slackness... Hip Hip!

GazL · 02-18-2016, 06:00 AM

BTW, as for the existing dns patch going forward. Might be worth keeping it until they fix this:
https://sourceware.org/bugzilla/show_bug.cgi?id=19646

Yes, they've just opened a bug report for the issue the comments in our 8 year old patch are referring to.
The mind boggles.

qweasd · 02-18-2016, 03:05 PM

Quote:

Originally Posted by GazL

IMO Pat is right to patch current as the underlying overflows are still present and alternative vectors for exploiting them might show up in the future, but Pat's "slackness" with regard to removing the dns patch does seem to have resulted in us dodging a pretty nasty bullet!

Three cheers for His Slackness... Hip Hip!

Oh absolutely. There are basically just two approaches to a simple and stable OS: the Slackware way and... Sorry, I am too lazy to finish this thought, but you get the idea.