| |||||||||||||
Secrecy and the DNS flawSecrecy and the DNS flawPosted Jul 10, 2008 13:17 UTC (Thu) by emk (guest, #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 bugor will do so very soon. As usual, the only people left in the dark will be the white hats and the working system administrators. Im 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 wont say why. The patches broke quite a few Ruby applications, andto make matters worsethe 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 weeks embargo. But for Kaminsky to request that people not discuss why their systems are vulnerable is ridiculous. As system administrators, its 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, hes 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 (guest, #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, Im not arguing that Kaminsky should publish exploit code. But it would be nice to know, soon, what the actual threat is. Theres a big difference between describing a problem, and actually publishing exploit code. I once maintained an (incredibly minor) fork of a DNS implementation. It wasnt a caching resolver, so Im assuming its 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.
|
|||||||||||||