Constant resolver crashes after fiesty upgrade

[txshtkckr]

There are really two separate issues here:

1) At some point (I think during the upgrade to fiesty, possibly for the purpose of ipv6 configuration), Ubuntu decided to "beautify" my hosts file. I use Mike's ad-blocking hosts file (see http://everythingisnt.com/hosts.html) which points several advertising URLs to 127.0.0.1, and the beautification code collapsed this all into a single entry. This is as annoying as it is pointless.

2) The really long line that this produced in /etc/hosts crashes the glibc resolver code.

Background/Evidence:

After upgrading to Fiesty, I found that several network applications broke, including Java, telnet, wget, firefox, etc. They would all work normally most of the time, except that Java would regularly crash firefox. The trace from Java invariably showed up as happening here:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.6+0x6f34c] memcpy+0x1c
C [libc.so.6+0x58001] _IO_getline+0x41
C [libc.so.6+0x602eb] fgets_unlocked+0x5b
C [libnss_files.so.2+0x2f8a]
C [libnss_files.so.2+0x36df] _nss_files_gethostbyname2_r+0xaf

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress;+0
j java.net.InetAddress$1.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress;+4
j java.net.InetAddress.getAddressFromNameService(Ljava/lang/String;)Ljava/lang/Object;+17
[...]

Using gdb on "telnet localhost" gave me this:

[...]
Program received signal SIGSEGV, Segmentation fault.
0xb7d3d97e in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7d3d97e in ?? () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d3e998 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6
[...]

And strace on "telnet localhost" gave me this:

[...]
munmap(0xb7f63000, 4096) = 0
open("/etc/hosts", O_RDONLY) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=257457, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f63000
read(3, "\n127.0.0.1 localhost loopback\n12"..., 4096) = 4096
read(3, "s.autotrader.co.za adserving.aut"..., 4096) = 4096
close(3) = 0
munmap(0xb7f63000, 4096) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 8081 detached

I have not checked the source, but my gut feeling is that the code is not correctly handling the case of not finding a newline within 4K chars and is overrunning the end of the buffer. I'm at a loss as to how this would be exploited, but any buffer overrun in something as commonly used as the resolver code alarms me, so I've checked the security vulnerability checkbox just in case.

I will attach a hosts file that reproduces the issue.

[Kees Cook (kees)]

Thanks for reporting this. I had seen other reports about this, but I remain unable to reproduce the problem. I will try this on a few other machines shortly and get back to you. Thanks again!

[Kees Cook (kees)]

Okay, this is confirmed. It appears to be stack exhaustion within libc while handling nss_files's getent call to read a 200K line from the /etc/hosts file:

              while (1)
                {
                  rc = __gethostbyname2_r (name, family, &th, tmpbuf,
                                           tmpbuflen, &h, &herrno);
                  if (rc != ERANGE || herrno != NETDB_INTERNAL)
                    break;
                  tmpbuf = extend_alloca (tmpbuf, tmpbuflen, 2 * tmpbuflen);
                }

This extend_alloca eventually reaches way above stack memory and seg faults. This problem seems specific to nss_files, and requires a very unusual local configuration, so I'm going to unmark this a private security issue. Thanks!

[CoderGuy (alec-bickerton)]

I'm seeing this same issue. for me it's important as I have to disable my hostsfile if I want to use java at all.