Re: DNS vulnerability: other relevant software

[Nathanael Hoyle <nhoyle () hoyletech com>]

Bernhard R. Link wrote:
> * Nathanael Hoyle <nhoyle () hoyletech 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