////////////////////////////////////////////////////////////////////////// I have got a couple of messages stating that I am wrong and that the resolver vulnerability sent to list by Oliver Friedrichs (oliver@secnet.com) is a new one. Our discussion with Oliver outlined that even though it is possible that this vulnerability was discussed during BOFs at conferences such as LISA, SANS and NETSEC, neither a summary was ever made public, nor a detailed description of attack was ever given. The SNI Security Advisory posted to linux-security provided not only a really good summary with an explanation of attacks targetting the resolver but also provided a detailed description of them. I appologise for blindly assuming that readers of the mailing list were aware of these problems. The following is an extract from the follow up message sent by Oliver Friedrichs <oliver@secnet.com> (used with permission)> The argument that I make (and the argument explaining the reason why we > assumed it was new), is that Paul Vixie himself was not aware of this > problem until we notified him. This is not to mention that CERT was not > aware of the problem either. The other interesting fact is that the BIND > resolver, up until the latest official release (and beta releases), has > been vulnerable to this attack. The fix apparantly being made by fluke, > after incorporating IPv6 support. > > I have also never seen any other reference to this anywhere else (yes > there has been alot of talk about h_name problems in various places, > causing string buffer overflows, yet not the h_length problem). > > I also feel it is important to point out that, this bug whether new or old > has not been addressed. Even if the bug was discussed at SANS or elsewhere > it does not change the fact that it is a very serious, very immediate > threat. Effecting everything from personal workstations to corporate > firewalls. Discussing it, e-mailing about it, or any other type of > communication in limited forums will end with the bug still being a > problem. With this in mind, we released the advisory.Alex From mail@mail.redhat.com relay2.redhat.com dutecai.et.tudelft.nl by (8.6.10/1.34JP)
> possible that this vulnerability was discussed during BOFs at conferences > such as LISA, SANS and NETSEC, neither a summary was ever made public, nor a > detailed description of attack was ever given.The attack is NOT new news. I got the rcmd() code in gnu libc fixed a while ago and sent a "fix this ask no questions message" to HJ Lu as well (for libc5). Looking at the 5.4.10 code it doesnt appear it got fixed. Im not sure if resolv+ has that bug anyway however. Also if you remember I moaned at someone [Bill Fenner I think] on here who posted a big ping program that assumed the resolver gave back good lengths and got a reply saying I was talking crap.. now you know why I said it.> > problem until we notified him. This is not to mention that CERT was not > > aware of the problem either. The other interesting fact is that the BINDWho made the claim CERT were not aware of that ?> > I have also never seen any other reference to this anywhere else (yes > > there has been alot of talk about h_name problems in various places, > > causing string buffer overflows, yet not the h_length problem).The DOMAIN_TRIM stuff in resolv+ also has buffer overrun bugs. It doesnt check the lengths.> > firewalls. Discussing it, e-mailing about it, or any other type of > > communication in limited forums will end with the bug still being a > > problem. With this in mind, we released the advisory.Until someone confirms CERT themselves made that claim I reserve judgment on their issues. Thank you for making it public [and there is no sarcasm in that sentence]. CERT do [and Im not in the mood to argue for or against their policy on a list like this] sit on bugs and pass them to limited audiences to fix before they become public knowledge. That is how gnulibc rcmd() got fixed. Unfortunately at times they let vendors sit on things for far too long (eg the solaris priviledged socket bug). I''m in the sometimes awkward position of being both on the full disclosure lists and sometimes doing Linux stuff related to CERT which is non disclosure. That makes it sometimes awkward to resolve the two conflicting issues. Thus what I hear from CERT but not from anyone else stays PGP encrypted on a secure machine at home. What I hear from everyone else I tell everyone else about. And yes I have known about resolv for a long time. Alan From mail@mail.redhat.com 14592 from invoked 13 network);
>Also if you remember I moaned at someone [Bill Fenner I think] on here who >posted a big ping program that assumed the resolver gave back good lengths >and got a reply saying I was talking crap.. now you know why I said it.You''re right. I should never have released a program that I originally wrote for a limited audience, and for that, I apologize. (The resolver library on the system on which I wrote the program did not have that bug). Bill