Re: update on the djbdns bugs? (fwd)

For &*@%#'s sake, Dean... It's not a contest to see who can figure  
something out first and make a post about it.

You had engaged Dan Kaminsky(who I've only first talked to in the last  
couple of months), Paul Theodoropoulos (who I first talked to in the  
last few days) and I in an off-list series of accusations about some  
kind of conspiracy with ISC or a "BIND Cartel". You also complained  
(rightly so) that I was taking too long to divulge anything.

I explained in a bit more detail why I wasn't able to right away. You  
continued asserting that Dan and I were somehow trying to make djbdns  
look bad, so we privately let you in on a little bit of it. You still  
weren't convinced, so I offer you a draft copy of what I was about to  
release, only asking for your assurance that you weren't going to leak  
it before a few notifications happened. No response at all from you  
until I see this. I'd already asked you once not to post a private  
reply onto the list before this. Other than parroting a few things we  
said about spoofing attacks in general, the only thing you've done  
here is ensure no-one working on something security related shares  
anything with you privately again.

For everybody else watching:

I am very sorry for the delays in bringing everything out in the open.  
I hadn't intended on saying a word until it was all public. I believe  
I've written the final draft, so consider a release "imminent".

This isn't some kind of FUD attempt, either. I'm a djbdns user myself.  
A few people on this list have been given a preview of my document to  
help proofread it, they're invited to confirm that I'm not making  
things up. :)

I fully support anyone who finds any defect in any software to  
disclose it at whatever schedule they like. I'm just a tad annoyed  
with Mr. Anderson for twice moving a private discussion back into  
public view when I'd asked otherwise.

This problem isn't earth-shattering. Knowing what I know, I still am  
using djbdns on my production network. There is no need for this level  
of drama over something that I believe most will consider more  
academic than practical.


-- Kevin


On Oct 4, 2008, at 4:11 PM, Dean Anderson wrote:

> Actaully, I do see a problem that I _think_ might be what Kaminsky and
> Day assert, but it isn't as bad as asserted. The packetquery()  
> function
> does not check to see if the query is already in progress, so it may  
> be
> possible to start up to 200 (MAXUDP) repeats of the same query only,  
> but
> only if there is a dead server. The dead server is needed to extend  
> the
> response time long enough to execute an attack.  If the server is  
> live,
> there probably isn't enough time to execute the attack before the
> correct response is received.
>
> (DJBDNS, outstanding queries)
> model B (2 urns, no replacement)
> p4(64510, 200, 200)
> exact formula: 1 - (perm(m, n1+n2) / (perm(m, n1) * perm(m, n2))
>   simplified (n1 = n2): 1 - (perm(m, 2n) / (perm(m,n) ^ 2))
> (%i48)  float( 1 - ( 64510! / ( 64510 - 400)! ) / ( ( 64510! /  
> ( 64510 -
> 200)! ) ^ 2 ) );
> (%o48)                         0.46312147260386
> (%i49) % * (1/65536);
> (%o49)                       7.066672860776713E-6
> (%i50) 1 / %;
> (%o50)                         141509.3099258154
> (%i51) 200 * %;
> (%o51)                       2.830186198516307E+7
>
> One needs to send 28 million packets in 120 seconds.  For the smallest
> query, this works out to a bit rate of 120mbs.  Possible on a gigE.
>
> It might not be unreasonable to discard packets with duplicated  
> queries,
> but this seems not ideal to me. Alternatively, one could try to  
> queue up
> the list of clients making the same query and answer all when the  
> query
> is resolved.
>
> Another easy fix would be to count the number of duplicated queries,  
> and
> not allow more than some small (configurable) number of duplicates.  
> This
> could be done with a slight change to packetquery(). Allowing only 10
> duplicate queries requires an attacker to send 423 million packets in
> 120 seconds, requiring a bitrate of 1.8Gbps.  I suggest also checking
> for duplicate outstanding queries when a correct response is received,
> and dropping the outstanding requests, another simple change.  This
> attack could be detected by counting the number of irrelevant  
> responses,
> and just dropping the udp query above a certain threshold, changing
> immediately to TCP.
>
> Thoughts?
>
> (%i62) float( 1 - ( 64510! / ( 64510 - 20)! ) / ( ( 64510! / ( 64510 -
> 10)! ) ^ 2 ) );
> (%o62)                        0.0015491743732935
> (%i63) % * (1/65536);
> (%o63)                       2.363852498311612E-8
> (%i64) 1 / %;
> (%o64)                       4.2303823978621878E+7
> (%i65) 10 * %;
> (%o65)                       4.2303823978621876E+8
> (%i66) % / 120;
> (%o66)                         3525318.664885156
> (%i67) % * 64;
> (%o67)                        2.2562039455265E+8
> (%i68) % * 8;
> (%o68)                        1.8049631564212E+9
>
>
> 		--Dean
>
>
> -- 
> Av8 Internet   Prepared to pay a premium for better service?
> www.av8.net         faster, more reliable, better service
> 617 344 9000
>
>