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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46AA4537.5030400@gmail.com>
Date: Fri, 27 Jul 2007 21:19:19 +0200
From: Amit Klein <aksecurity@...il.com>
To: Gadi Evron <ge@...uxbox.org>
Cc: Jamie Riden <jamie.riden@...il.com>, bugtraq@...urityfocus.com
Subject: Re: "BIND 9 DNS Cache Poisoning" by Amit Klein (Trusteer)

I'm put in an awkward position of having to respond to a message which 
wasn't sent to me in the first place. But still...

"This bug was reported over and over again" - I find this statement 
confusing. The bug class of "DNS transaction ID not being random enough" 
was sure reported for several DNS server, including BIND. My paper 
clearly references e.g. 
http://www.openbsd.org/advisories/res_random.txt (as reference [7]). 
However, I'm not familiar with public reports that outline the 
seriousness of the non-randomness of BIND *9*, to the extent my report 
did. So the way I see it is that this particular bug, in BIND 9, was not 
explicitly reported before.

"it's not like this hasn't been reported, and fixed, many times by many 
others" - so if it's fixed so many times, how come it was still 
vulnerable, and ISC had to issue their patches?

-Amit

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.
> -----
>
>     Gadi.
>