[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
