oss-sec mailing list archives
Re: DNS vulnerability: other relevant software
From: Nathanael Hoyle <nhoyle () hoyletech com>
Date: Thu, 10 Jul 2008 22:51:59 -0400
Eugene Teo wrote:
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.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=32c1da70810017a98aa6c431a5494a302b6b9a30Is 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
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
Current thread:
- DNS vulnerability: other relevant software Matthias Geerdsen (Jul 09)
- Re: DNS vulnerability: other relevant software The Fungi (Jul 09)
- Re: DNS vulnerability: other relevant software Mark J Cox (Jul 09)
- Re: DNS vulnerability: other relevant software Florian Weimer (Jul 09)
- Re: DNS vulnerability: other relevant software Eugene Teo (Jul 09)
- Re: DNS vulnerability: other relevant software Eugene Teo (Jul 09)
- Re: DNS vulnerability: other relevant software Eugene Teo (Jul 10)
- Re: DNS vulnerability: other relevant software Nathanael Hoyle (Jul 10)
- Re: DNS vulnerability: other relevant software Bernhard R. Link (Jul 11)
- Re: DNS vulnerability: other relevant software Nathanael Hoyle (Jul 11)
- Re: DNS vulnerability: other relevant software Florian Weimer (Jul 13)
- Re: DNS vulnerability: other relevant software Mark J Cox (Jul 09)
- Re: DNS vulnerability: other relevant software The Fungi (Jul 09)
- Re: DNS vulnerability: other relevant software Florian Weimer (Jul 12)
- Re: DNS vulnerability: other relevant software Eugene Teo (Jul 09)