Date: Thu, 10 Jul 2008 22:51:59 -0400
From: Nathanael Hoyle <nhoyle@...letech.com>
To: oss-security@...ts.openwall.com
Subject: Re: DNS vulnerability: other relevant software

Eugene Teo wrote:
> Eugene Teo wrote:
>   
>> Eugene Teo wrote:
>>     
>>> Florian Weimer wrote:
>>>       
>>>> * Mark J. Cox:
>>>>
>>>>         
>>>>>> Additionally, Debian has noted (DSA 1605-1) that the GNU libc stub
>>>>>> resolver could benefit from random query source ports as well, but
>>>>>> no patches are currently available to implement this:
>>>>>>             
>>>>> Note that GNU libc stub resolver when used with a recent kernel
>>>>> (2.6.24+) will give you random UDP source ports on each request
>>>>> because of this Linux commit:
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30
>>>>>           
>>>> Is net_random() cryptographically secure?  The paper referenced in the
>>>> source doesn't talk about this.
>>>>         
>>> It isn't. It's actually a 32-bit pseudo-random number generator AFAIK.
>>>       
>
> So I spoke to Dave Miller. He said that it is not "cryptographically
> secure" to his knowledge, but in his opinion, it is good enough for port
> randomisation.
>
> Thanks, Eugene
>   
There are only two types of "random" that I'm aware of.  
Cryptographically secure, with values drawn from an entropy pool 
populated by capturing some unpredictable real-world input, and not 
cryptographically secure, which are seeded with a random value 
(typically something like the number of milliseconds since midnight or 
some such changing value) and then use a (albeit complex) deterministic 
mathematical progression to arrive at each subsequent value.

Let us think about this for a moment in the context of source port 
randomization as a security measure, particularly in the open source 
world (the attack against a closed-source system is merely more 
difficult, due to reversing the algorithms, not impossible):

We can divide our attackers into two classes.  Those able to see the 
traffic generated by the DNS resolver request, and those not.  Those not 
able to see the traffic (in either direction) are not interesting for 
purposes of random sequence generation analysis.  Those who can are 
where we must be concerned.  We must accept, that with an open source 
kernel PRNG implementation, and/or DNS resolver PRNG implementation, the 
algorithm will be known.  What is not known is the seed, and therefore 
the next value.  An attacker who can watch traffic can capture a 
sequence of source ports used.  Each one reduces the set of seed values 
which would generate that sequence using the known algorithm.  The 
attack becomes much like attacks on wireless encryption... just 
collecting packets quietly and further narrowing the possible seed 
values.  There was a story not too long ago about some guys who used an 
attack like that to zero in on the seed value for certain games in 
casinos that had computerized backends and take the house to the cleaners.

Now, for a busy DNS server, many queries are being generated every 
second, but if we are marching in "lock-step" with the current PRNG 
values with a matched implementation and seed, we can spam a bunch of 
replies back to it which all have ports which are within the next few to 
be used... effectively mitigating the defense.  How much security is 
gained depends on how busy the DNS server is, and how hard it is to 
observe the packets and stay in sync in realtime, but it certainly 
doesn't sound like a good defense.  If there is a protocol issue (I'm 
looking forward to hearing what Kaminsky has found), obviously it needs 
to be addressed.  In the meantime, I would say that 
non-cryptographically secure port randomization is a band-aid on a 
compound fracture.

Just my 2 cents.  I know Dave Miller is a smart guy, and has some 
serious secure coding background, but I have to wonder about "good 
enough for DNS" if it's being relied upon for security.

-Nathanael

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux