"D. J. Bernstein" <djbat_private> 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 Weimerat_private-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
This archive was generated by hypermail 2b30 : Thu Jul 04 2002 - 14:37:33 PDT