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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.