User: Password:
|
|
Subscribe / Log in / New account

Secrecy and the DNS flaw

Secrecy and the DNS flaw

Posted Jul 10, 2008 13:17 UTC (Thu) by emk (subscriber, #1128)
Parent article: Secrecy and the DNS flaw

I think Kaminsky steps over the line when he says, “Please, keep the speculation off the @public forums and IRC channels.”

At this point, we have to assume that the black hats have already puzzled out the bug—or will do so very soon. As usual, the only people left in the dark will be the white hats and the working system administrators.

I’m still pretty annoyed at the handling of the recent security bugs in Ruby. The Ruby developers said, “Here are some security patches which you must apply right now, but we won’t say why.” The patches broke quite a few Ruby applications, and—to make matters worse—the actual bugs had been publicly described in Ruby's source tree. Once you release patches, the bug is almost always a matter of public record, at least for anyone who cares to think about it for while. (The exception, perhaps, was the remote hole in ssh, which was first patched by privilege separation.)

In the case of the DNS bug, I could understand a week’s embargo. But for Kaminsky to request that people not discuss why their systems are vulnerable is ridiculous. As system administrators, it’s our job to secure our employers’ systems. And to do that, we need to be able to discuss security problems. And since Kaminsky specifically requests keeping speculation out of public forums, he’s admitting that he expects other people to figure it out, presumably including sufficiently dedicated black hats. So what purpose is served by the embargo?


(Log in to post comments)

Secrecy and the DNS flaw

Posted Jul 10, 2008 15:12 UTC (Thu) by copsewood (subscriber, #199) [Link]

I think enough has been published concerning the flaw so that white hats should by now know
enough about the nature of it to remediate the vulnerability, without specific attack code
having to be published before they have a chance to do so. It's not as if the source code for
the patches is kept secret, and if you don't know enough about how DNS works this information
isn't a secret either. The problem seems to be that weak and pseudo-randomisation of source
ports and transaction IDs isn't good enough for PRNGs whose source code or algorithm is
available. This is because we can deduce that the Kaminsky attack, when it is published, will
be based on determining the internal state of the PRNG by carrying out some DNS enquiries
possibly in connection with an attacker enticing a victim to resolve an attacker chosen-domain
name. I would guess, without having read the patches, that the internal state of the PRNG has
to be more heavily disguised, or possibly the PRNG having to be more frequently reseeded using
genuine entropy or even a multi-threaded DNS caching server having per-thread state
independent PRNGs. 

Assuming the attack involves discovering the internal state of the PRNG then subsequent source
ports and transaction IDs in a sequence can be guessed based on knowledge of previous ones.
You don't really need to know yet how the internal PRNG state can be discovered to take
reasonable steps to prevent this information from being discovered. For the most part admins
will just apply the patches as usual. Those who really need to know more will be those who are
developing and running less popular DNS caching recursive resolvers who were not party to the
prior restricted disclosure, and which are not easily replaceable using standard DNS programs
for some reason. In connection with those who have to run non-standard and unpatchable DNS
client libraries and who also can't trust their upstream ISP connection to their ISPs DNS
resolving server not to be sniffed with MITM UDP packet injection capability attacks, they
would do well either to use VPNs to an ISP network with more trusted properties or a local and
trusted DNS resolver. This could happen over an insecure wireless network, but for those
operating such networks, attacks against unpatchable DNS clients are not likely to be amongst
their greatest worries.

Secrecy and the DNS flaw

Posted Jul 10, 2008 18:10 UTC (Thu) by emk (subscriber, #1128) [Link]

I think enough has been published concerning the flaw so that white hats should by now know enough about the nature of it to remediate the vulnerability, without specific attack code having to be published before they have a chance to do so.

Just to clarify my earlier remarks, I’m not arguing that Kaminsky should publish exploit code. But it would be nice to know, soon, what the actual threat is. There’s a big difference between describing a problem, and actually publishing exploit code.

I once maintained an (incredibly minor) fork of a DNS implementation. It wasn’t a caching resolver, so I’m assuming it’s not affected. But I'd feel happier if I actually understood the problem.

In response to your other remarks, I really hope this isn't a weak PRNG problem. That would be pretty embarrassing.

Secrecy and the DNS flaw

Posted Jul 11, 2008 0:12 UTC (Fri) by njs (guest, #40338) [Link]

It seems unlikely that the problem is really a PRNG flaw, because we know how to build good
PRNGs.  Not every implementation might *use* such a PRNG, but if it were a PRNG flaw then it
would only affect those implementations that were using poor PRNGs, not every implementation.

Secrecy and the DNS flaw

Posted Jul 12, 2008 10:32 UTC (Sat) by copsewood (subscriber, #199) [Link]

What do you mean by a "good" PRNG ? I think what we understand to be good here might have to
change. It's one thing for a PRNG to generate a sequence of numbers with good statistical
properties and which doesn't repeat its inherently predictable sequence until a very large
integer number space is exhausted. It's entirely another to have a PRNG with a published
algorithm and an attacker able to obtain prior information relevant to its internal state but
provably unable to predict the subsequent sequence of numbers generated. The P here means
pseudo, because the randomness isn't randomness at all - it means that the sequence of numbers
is generated using an algorithm and not a noise source. Certainly the developer and
administrator can attempt to reseed such an algorithm periodically and cryptically. The issue
is how much can an attacker learn by knowing previous numbers in the sequence in order to
predict subsequent numbers in the sequence.

One solution for the paranoid is to use /dev/random instead of /dev/urandom as the entropy
source. This is a good idea when generating cryptographic keys intended for medium-long term
use, but running a DNS recursive resolving server which needs to generate thousands of
unpredictable source port numbers and transaction IDs a second is going to need a faster
entropy source than /dev/random hence the need for a PRNG in the first place.

Secrecy and the DNS flaw

Posted Jul 12, 2008 20:56 UTC (Sat) by njs (guest, #40338) [Link]

Indeed, the study of PRNGs splits into two parts: scientific PRNGs, where the emphasis is on
provable uniformity, provably large period, and speed, versus cryptographic PRNGs, where the
emphasis is on resistance to prediction, judicious incorporation of true entropy, and speed.
As you suggest, since DNS port randomization is effectively using the source port as part of a
secret key, it's important that the the source ports be generated by a cryptographic PRNG.

Fortunately, these days we can build very good PRNGs of both types.  For cPRNGs, the
constructions usually involve using some other crypto algorithm as part of the generation
process (e.g., a strong hash or cipher like SHA-256 or AES).  This is exactly what /dev/random
and /dev/urandom do, and it's what good-quality DNS server implementations will do too.  In
practice, attacking such a PRNG is about as easy as inverting SHA or AES -- not gonna happen.
(And yes, I know that SHA-1 has been recently weakened.)

If you want to know more about these issues, then I can recommend Schneier's paper on
yarrow[1] for a great discussion of the issues faced by such a design, and [2] for a fun and
famous discussion of exploiting such flaws in TCP sequence numbers (with pretty pictures!).

[1] http://www.schneier.com/yarrow.html
[2] http://lcamtuf.coredump.cx/oldtcp/tcpseq.html

Secrecy and the DNS flaw

Posted Jul 17, 2008 10:29 UTC (Thu) by copsewood (subscriber, #199) [Link]

Thanks for these links which are very interesting.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds