On Wed, Jul 09, 2008 at 05:36:02PM +0100, Ben Laurie wrote:
> Paul Hoffman wrote:
>> First off, big props to Dan for getting this problem fixed in a 
>> responsible manner. If there were widespread real attacks first, it would 
>> take forever to get fixes out into the field.
>> However, we in the security circles don't need to spread the "Kaminsky 
>> finds" meme. Take a look at 
>> <http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/>. 
>> The first draft of this openly-published document was in January 2007. It 
>> is now in WG last call.
>> The take-away here is not that "Dan didn't discover the problem", but "Dan 
>> got it fixed". An alternate take-away is that IETF BCPs don't make nearly 
>> as much difference as a diligent security expert with a good name.
> Guess you need to tell Dan that - he seems to think he did discover it.

Taking a brief look at what changed in bind, it seems primarily to
involve randomizing the query port, matching both the port and
transaction id instead of just the id, and using RC4 to generate the
transactions ids instead of a pair of very sketchy-looking
(cryptographically speaking) RNGs based on an LCRNG design via Knuth.

Perhaps there is something subtle here that is more dangerous than the
well known problems, and all these source port randomization and
transaction id randomization fixes are just a smokescreen of sorts for
a fix for something Dan found.

Securosis claims [1] "The good news is that due to the nature of this
problem, it is extremely difficult to determine the vulnerability
merely by analyzing the patches", and Dan claims something similar,
offering to share the stage at Defcon with anyone who finds the
bug [2]

A statement from the MaraDNS author [3]:

MaraDNS is immune to the new cache poisoning attack.  MaraDNS has
always been immune to this attack.  Ditto with Deadwood (indeed,
people can use MaraDNS or Deadwood on the loopback interface to
protect their machines from this attack).

OK, basically, this is an old problem DJB wrote about well over seven
years ago.  The solution is to randomize both the query ID and the
source port; MaraDNS/Deadwood do this (and have been doing this since
around the time of their first public releases that could resolve DNS
queries) using a cryptographically strong random number generator
(MaraDNS uses an AES variant; Deadwood uses the 32-bit version of
Radio Gatun).

(But CERT has no reply in their advisory from MaraDNS, so I'm not sure
if this statement was made on the basis of just what is publically
known, or if he was in fact in on the vendor notify list).


[2] http://www.doxpara.com/?p=1162
[3] http://marc.info/?l=maradns-list&m=121560639013865&w=2

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to