"D. J. Bernstein" <djb@cr.yp.to> writes:
> 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 Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
