[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080711093700.GA8987@pcpool00.mathematik.uni-freiburg.de>
Date: Fri, 11 Jul 2008 11:37:00 +0200
From: "Bernhard R. Link" <brlink@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: DNS vulnerability: other relevant software
* 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).
> 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).
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?
> 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.
> 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).
> 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
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.
