[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <487757C4.2000206@hoyletech.com>
Date: Fri, 11 Jul 2008 08:53:24 -0400
From: Nathanael Hoyle <nhoyle@...letech.com>
To: oss-security@...ts.openwall.com
Subject: Re: DNS vulnerability: other relevant software
Bernhard R. Link wrote:
> * Nathanael Hoyle <nhoyle@...letech.com> [080711 05:17]:
>
>> 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.
>>
>
> This is both very black-white and too theoretical to fit reality.
> Different algorithms are differently predictable. Also really
> "unpredictable" randomness is usually extremly scarce. The majority
> of computers has no built-in source for this, so has only very few bits.
> Misusing those for things where it is not necessary will cause
> everything more important to be less secure. (And not really make a
> difference in this case, as this service will also run out of randomness
> and either has to cease service (impossible) or fall back to some
> pseudo-randomness).
>
>
Agreed. I simplified slightly in separating RNG into two classes. Also
acknowledge that most sites don't have military-style hardware gathering
EM radio noise or such things for random entropy pools and don't have a
good source of real randomness. I realize that using your real entropy
pool to generate source ports for a busy DNS server can exhaust the pool
and reduce security in the absence of such entropy sources. This
introduction was not meant to advocate cryptographically secure RNG in
all cases as it was to point out the silliness of PRNG as a security
defense.
>> 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.
>>
>
> I think there are some more different scenarios. An attacker might
> see only parts of the traffic (by example causing requests to his
> server, for example by some images embedded into a trojaned website).
>
>
A valid case I did not consider. This would obviously not allow the
described attack.
> Here it is important that this part does not give enough information
> to predict other requests.
>
>
>> 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.
>>
>
> I do not see much point in that. When the attacker can see anything, why
> not just wait for the actual request and answer it? Why guess the source
> port if you can know it exactly?
>
>
Depending on how busy the target DNS resolver is and how much latency
exists in your observation of the queries, it may not be possible to
generate replies after seeing the request that have a chance to be the
first reply. Rather, being able to "lead your target" (as you would
shooting at a moving target) and generate answer for the ports *about*
to be used could allow an attack where it would not otherwise be possible.
>> Now, for a busy DNS server, many queries are being generated every
>> second,
>>
>
> if there are many queries, I think attacking only gets harder, because
> guessing the order of requests gets harder to predict, adding more
> variables.
>
>
Agreed, I referred to this.
>> If there is a protocol issue (I'm
>> looking forward to hearing what Kaminsky has found), obviously it needs
>> to be addressed.
>>
>
> I'm also looking forward to this. I was under the impression that is was
> common knowledg that dns is simply insecure, everyone trusting on it is
> insane, and security issues meaning it is easier to hijack than it
> should be (like dns servers accepting answers for things they never
> asked for and things like that).
>
>
Agreed. Important communications need to take place through properly
authenticated (i.e. SSL with a real CA) sessions. Using static name
resolution (i.e. /etc/hosts) for certain hosts (ugly, but sometimes used
if only a couple sites are sensitive), or DNSSEC (which is the eventual
answer, I think) are other possibilities.
>> In the meantime, I would say that
>> non-cryptographically secure port randomization is a band-aid on a
>> compound fracture.
>>
>
> But using real entropy for port randomization even on hosts not having
> dedicated hardware to produce it is curing a compound fracture by
> amputation.
>
> Bernhard R. Link
>
Quite likely. My point was that it strikes me as somewhat snake-oil-ish
to advocate PRNG with a known algorithm as a security defense. It
increases the difficulty of attack somewhat, but I hardly believe it
addresses whatever the underlying issue is. The thread made it look
like the back-porting of the linux kernel change was going to be
considered a "resolution" for the issue, when it hardly seems like that.
-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.
