Quoting likot ([EMAIL PROTECTED]): > well that was the first advisory but was _corrected_ > http://online.securityfocus.com/archive/1/280642/2002-09-17/2002-09-23/2
That's _not_ a CERT advisory, but rather a Bernstein post saying he doesn't approve of ISC's reasoning about the corrective effect of BIND9 caching. (He doesn't dispute the factual claim, exactly; he just doesn't think it's adequate protection.) > http://online.securityfocus.com/archive/1/280706/2002-09-17/2002-09-23/2 That's not a CERT advisory _either_, but rather Florian Weimer analysing Bernstein's post, finding it to have been somewhat illogical in attributing a sweeping meaning to ISC's statement not present in the original -- and commenting further. > this was the new advisory > http://www.kb.cert.org/vuls/id/803539 OK, but that corrects the advisory basically only in giving more detail and clarifying that most BSD-derived resolvers are effected (including the then-current glibc ones) because they used derived/related code. But the resolver in question is _still_ BIND 8.x's. As I said. And, as I also said, the problem with BIND 4.x/8.x code all along is that it was acknowledged spaghetti code from some long-ago UC Berkeley graduate students. We knew that already. Nominum didn't write that code; they wrote BIND9. > suprisingly enough another sendmail issue was included > <quote> > > (3) A sendmail 8.12 issue which involves DNS TXT > records > (see http://www.kb.cert.org/vuls/id/814627). > </quote> Quoting that advisory (in bold type, right near the top): Please note that the Sendmail Consortium has indicated that this vulnerability is not present in the standard Sendmail distribution because the option that can trigger the exposure is not enabled. In other words, the theoretically vulnerable configuration would be an extremely wacky and unlikely one: You'd have to have (1) gone out of your way to write a DNS map and used it to query DNS "TXT" records (_why?_), and (2) happen to have sent those queries to a rogue, compromised DNS daemon somewhere run by someone else who is deliberately trying to send out oversized "TXT" resource records in hopes of inducing a buffer overflow. I don't when is the last time that _you_ did a huge amount of otherwise unnecessary work to make your MTA query DNS records for "TXT" DNS information. If you have, please do tell: I'm desperately curious about what the heck you were doing. Hell, do you even _know_ anyone who so much as _uses_ TXT records in their zonefiles? Let alone configure their SMTP servers to look them up for God-only-knows-what reason? See the thing about security advisories is that you have to actually _read_ them, before they're any use at all. > as to UUCP > http://cr.yp.to/qmail/faq/outgoing.html#uucp Ah, cool! Good to know qmail can do that. -- Cheers, "Open your present...." Rick Moen "No, you open your present...." [EMAIL PROTECTED] Kaczinski Christmas. -- Unabomber Haiku Contest, CyberLaw mailing list _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
