Remote buffer overflow in resolver code of libc
Florian Weimer
> BIND company official David Conrad writes:
>> My understanding is that this will work with BINDv9 since the cache
>> synthesizes all responses returned to the requestor and a bad response
>> wouldn't be synthesized.
>
> What exactly do you mean by ``work,'' and by ``bad response''? And what
> exactly do you mean when you say that a BINDv9 cache ``can be used to
> prevent malformed answers reaching vulnerable clients''?
[snip]
> I presume that your statement is based on at least this much content:
> you've figured out _one_ type of packet that will trigger these buffer
> overflows, and you're sure that BINDv9 will never produce _that_ type of
> packet. But are you saying that _none_ of the packets produced by BINDv9
> will trigger these buffer overflows?
I'm sure the claim cited above only refers to the padding issues
described by PINE-CERT in their advisory. Another problem has been
discovered in the getnetby*() functions which most people regard the
same, but strictly speaking, it's an entirely different matter. I
wouldn't be surprised if this vulnerability could be exploited using
syntactically valid DNS responses.
A longer explanation of the current situation follows, summarizing
some of the data currently publicly available.
[The text below is a slightly edited version of a message circulated
over different channels. It contains no additional information.]
At the moment, we face three different DNS-related issues:
(1) Misuse of dn_expand(), which does not return the number of
extracted bytes, but the number of bytes consumed from the input
buffer (can be less than the first byte count).
(2) Complete lack of bounds checking in a subroutine used by the
getnetby*() functions.
(3) A sendmail 8.12 issue which involves DNS TXT records
(see http://www.kb.cert.org/vuls/id/814627).
(3) is a completely separate issue and is not covered further in this
message. (It's not a problem with typical sendmail configurations
anyway.)
I think on Wednesday last week, PINE-CERT announced (1), hinting that
it is BSD-specific. The *BSD people rapidly provided patches.
However, problem (1) is present in the resolver library shipped with
BIND 4.9.8 and earlier, so it affects a wider range of systems. In
1999, Olaf Kirch discovered this problem in the GNU libc code, and it
was fixed in GNU libc 2.1.3; current GNU libc is not vulnerable as a
result (see http://www.kb.cert.org/vuls/id/AAMN-5BMSW2). The resolver
library which is part of BIND 8 (and some versions of BIND 9) contains
a relict of problem (1), so systems using this resolver are affected.
Now to problem (2). Technically speaking, this is a different issue,
not related to the peculiarities of the dn_expand() return value. The
OpenBSD developers patched it on said Wednesday, while they were
addressing problem (1), and I don't know if it had been on the radar
screen of PINE-CERT at all. Problem (2) is present in the BIND 4.9.8
sources and earlier, it does *not* apply to BIND 8.3.2 and earlier (at
least no such change is in BIND 8.3.3). *However*, code affected by
(2) has been copied to the resolv/nss_dns code in GNU libc, which
means that GNU libc is vulnerable to this particular bug. (This has
been discovered by Andreas Schwab by SuSE Labs.)
What about workarounds? ISC claims that BIND 9 can filter out attacks
for (1) because they involve syntactically invalid DNS answers.
I'm not sure if this is the case with problem (2): most likely,
completely missing bounds checking is problematic for *any* kind of
answer, even a syntactically correct one. However, on GNU/Linux there
is a workaround, thanks to the Name Service Switch. If the "networks"
line in /etc/nsswitch.conf reads
networks: files
(this is the default at least on Debian GNU/Linux and Red Hat Linux
7.1), you are on the safe side. DNS queries are sent only if the
"dns" option is present. You can check whether your system sends DNS
queries in response tor getnetby*() function calls by running the
following small C program and watching the network traffic:
#include <netdb.h>
int
main (void)
{
(void) getnetbyaddr(0, AF_INET);
return 0;
}
Note that not all systems which offer the Name Service Switch are
affected by (2). (getnetbyaddr() can be called by tools like route(8)
and netstat(8), in case you wonder.)
--
Florian Weimer Wei...@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
D. J. Bernstein
http://cr.yp.to/djbdns/blurb/library.html (features)
http://cr.yp.to/djbdns/dns.html (high-level interface)
http://cr.yp.to/djbdns/dns_domain.html (low-level name functions)
http://cr.yp.to/djbdns/dns_packet.html (low-level packet functions)
http://cr.yp.to/djbdns/dns_transmit.html (async interface)
http://cr.yp.to/djbdns/dns_random.html (randomization interface)
The .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c,
dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c,
dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c,
dns_txt.c) and all necessary lower-level .[ch] files are now in the
public domain.
Note also that the list in http://cr.yp.to/djbdns/guarantee.html has
always included ``Buffer overflows allowing attackers to take over DNS
clients,'' although I didn't have a BIND example before now.
BIND company official David Conrad writes:
> My understanding is that this will work with BINDv9 since the cache
> synthesizes all responses returned to the requestor and a bad response
> wouldn't be synthesized.
What exactly do you mean by ``work,'' and by ``bad response''? And what
exactly do you mean when you say that a BINDv9 cache ``can be used to
prevent malformed answers reaching vulnerable clients''?
Are you saying that clients are protected if /etc/resolv.conf points to
a BINDv9 cache? That's obviously not true: the attacker can forge a
packet that appears to come from the cache.
Are you saying that clients are protected if /etc/resolv.conf points to
a BINDv9 cache and local forgeries are prevented by, say, IPSEC? Are you
promising that BINDv9 will protect clients in this situation? Will you
treat a flaw in this protection as (another) BINDv9 security hole?
A few people seem to think that this is what you're saying, and that
they don't need to panic, because they're using BINDv9 caches and IPSEC,
and they don't mind their caches having root access to all the clients.
Yes or no: Are they in danger?
I presume that your statement is based on at least this much content:
you've figured out _one_ type of packet that will trigger these buffer
overflows, and you're sure that BINDv9 will never produce _that_ type of
packet. But are you saying that _none_ of the packets produced by BINDv9
will trigger these buffer overflows?
If so, can you justify that statement? Exactly what packets do you
consider to be ``bad''? Why do you think that BINDv9 will never produce
``bad'' packets? Why do you think that these buffer overflows can't be
triggered except by ``bad'' packets?
Perhaps clients using the BIND company's buggy client libraries really
can be protected by the BINDv9 cache (or by dnscache). But I haven't
seen the analysis necessary to justify this claim. At this point it
isn't even clear whether the BIND company is making that claim.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago