Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: "BIND 9 DNS Cache Poisoning" by Amit Klein (Trusteer)

Subject: Re: "BIND 9 DNS Cache Poisoning" by Amit Klein (Trusteer)
Date: Fri, 27 Jul 2007 12:37:49 -0400
On Thu, Jul 26, 2007 at 11:40:55PM -0500, Gadi Evron wrote:
This is Paul Vixie's response on this, when I asked him for verification:

-----
this bug has been reported over and over again for a dozen years.  it's
odd to have to keep fixing it-- i fixed it in bind4 and bind8 when theo
de raadt offered me his random number generator to use.  bind9 should've
used that same one but apparently didn't.  note that with this fix, the
difficulty in poisoning someone's cache rises from "a few tens of seconds"
to "a few minutes".  it's a 16-bit field.  not a lot of room for
randomness or unpredictability.  only DNSSEC, a protocol change, fixes
this problem, which is fundamentally a protocol problem.  but since folks
just won't leave it alone and keep on reporting it year after decade, we
will keep on improving our random number generator for this dinky little
16-bit field.  i just wish the reporters wouldn't be so smarmy and self
congradulatory about it.  it's not like this hasn't been reported, and
fixed, many times by many others.
-----


Note that this conveniently ignores the option to use randomized port
numbers...  No, it is a pretty fix, but it sure does help.

tim

<Prev in Thread] Current Thread [Next in Thread>