Re: Kaminsky finds DNS exploit
* Jack Lloyd: Perhaps there is something subtle here that is more dangerous than the well known problems, and all these source port randomization and transaction id randomization fixes are just a smokescreen of sorts for a fix for something Dan found. It's not a smokescreen, it's a statistical workaround. CERT/CC mentions this: | It is important to note that without changes to the DNS protocol, such | as those that the DNS Security Extensions (DNSSEC) introduce, these | mitigations cannot completely prevent cache poisoning. http://www.kb.cert.org/vuls/id/800113 A statement from the MaraDNS author [3]: MaraDNS is immune to the new cache poisoning attack. I think the CERT/CC statement is more approriate. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
CERT/CC mentions this: | It is important to note that without changes to the DNS protocol, such | as those that the DNS Security Extensions (DNSSEC) introduce, these | mitigations cannot completely prevent cache poisoning. Why wouldn't switching to TCP lookups solve the problem? It's arguably more traffic than DNSSEC, but it has the large practical advantage that they actually work with deployed servers today. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
* John Levine: CERT/CC mentions this: | It is important to note that without changes to the DNS protocol, such | as those that the DNS Security Extensions (DNSSEC) introduce, these | mitigations cannot completely prevent cache poisoning. Why wouldn't switching to TCP lookups solve the problem? It requires code changes on both types of servers, in order to make them more scalable. It's arguably more traffic than DNSSEC, but it has the large practical advantage that they actually work with deployed servers today. Implementors say that in many cases, their software as it's currently implemented can't take the load. It's not much worse than web traffic, that's why I think it can be made to work (perhaps easier with kernel support, who knows). But code changes are apparently required. And once you need code changes, you can roll out DNSSEC--or some extended query ID with 64 additional bits of entropy. On top of that, some operators decided not to offer TCP service at all. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Mon, 14 Jul 2008 16:27:58 +0200 Florian Weimer [EMAIL PROTECTED] wrote: On top of that, some operators decided not to offer TCP service at all. Right. There's a common misconception, on both security and network operator mailing lists, that DNS servers use TCP only for zone transfers, and that all such connection requests should be blocked. See, for example, the NANOG thread starting at http://mailman.nanog.org/pipermail/nanog/2008-June/001240.html --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
At 4:27 PM +0200 7/14/08, Florian Weimer wrote: Implementors say that in many cases, their software as it's currently implemented can't take the load. It's not much worse than web traffic, that's why I think it can be made to work (perhaps easier with kernel support, who knows). But code changes are apparently required. That whole paragraph, taken together, makes no sense. And once you need code changes, you can roll out DNSSEC--or some extended query ID with 64 additional bits of entropy. There is a difference between code changes in the kernel for some systems (which you allude to above), code changes and a universal rollout in all DNS software (which you allude to at the end), and stable rollout of the DNSSEC trust anchor system in every significant zone and all resolvers. FWIW, only the latter has anything to do with this mailing list... --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Udhay Shankar N wrote, On 9/7/08 5:52 PM: I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? He's posted a quite long article on his blog http://www.doxpara.com/?p=1162 that looks like all the details he is likely to provide for the next 30 days. It does seem to address the speculation on this list about how the patch relates to stuff that has been known for years, Dan Bernstein's code, who knew what when, etc. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
* Paul Hoffman: The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. I haven't seen credible claims that the underlying issue can actually be fixed in the classic DNS protocol. There are workarounds on top of workarounds. A real fix requires more or less incompatible protocol changes, and at that point, it might be easier to deploy DNSSEC instead. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Kaminsky finds DNS exploit
I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? Udhay http://www.liquidmatrix.org/blog/2008/07/08/kaminsky-breaks-dns/ Kaminsky Breaks DNS Author: Dave Lewis July 8, 2008 at 2:21 pm · Filed under Patches, Vulnerability Well, sort of. Today Dan Kaminsky released a first, as far as I can recall. A coordinated patch was released today by Dan Kaminsky of IO Active that fixes a vulnerability that apparently exists in all DNS servers. Unlike other researchers who give up the gory details, Kaminsky took a wiser path by smiling and nodding. He’ll give up the goods at Black Hat in August. That should give folks enough time to patch their systems. snip -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Wed, 09 Jul 2008 11:22:58 +0530 Udhay Shankar N [EMAIL PROTECTED] wrote: I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? Udhay http://www.liquidmatrix.org/blog/2008/07/08/kaminsky-breaks-dns/ I'm curious about the details of the attack. Paul Vixie published the basic idea in 1995 at Usenix Security (http://www.usenix.org/publications/library/proceedings/security95/vixie.html) -- in a section titled What We Cannot Fix, he wrote: With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all. Obligatory crypto: the ISC web page on the attack notes DNSSEC is the only definitive solution for this issue. Understanding that immediate DNSSEC deployment is not a realistic expectation... --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
However, we in the security circles don't need to spread the Kaminsky finds meme. Quite right. Paul Vixie mentioned it in 1995, Dan Bernstein started distributing versions of dnscache with randomized port and sequence numbers in 2001. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. I suppose 13 years is kind of a long time, but better late than never. It would be modestly interesting to learn what is different now that motivated him to get people to fix it. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. Guess you need to tell Dan that - he seems to think he did discover it. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Wed, Jul 09, 2008 at 08:20:33AM -0700, Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. The discovery is almost certainly a generalization of: http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05#section-4.3 specifically the second paragraph the mentions the Birthday Attack. The assumptions of that paragraph can be relaxed in a natural way to broaden the scope of the attack. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Wed, Jul 09, 2008 at 05:36:02PM +0100, Ben Laurie wrote: Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. Guess you need to tell Dan that - he seems to think he did discover it. Taking a brief look at what changed in bind, it seems primarily to involve randomizing the query port, matching both the port and transaction id instead of just the id, and using RC4 to generate the transactions ids instead of a pair of very sketchy-looking (cryptographically speaking) RNGs based on an LCRNG design via Knuth. Perhaps there is something subtle here that is more dangerous than the well known problems, and all these source port randomization and transaction id randomization fixes are just a smokescreen of sorts for a fix for something Dan found. Securosis claims [1] The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches, and Dan claims something similar, offering to share the stage at Defcon with anyone who finds the bug [2] A statement from the MaraDNS author [3]: MaraDNS is immune to the new cache poisoning attack. MaraDNS has always been immune to this attack. Ditto with Deadwood (indeed, people can use MaraDNS or Deadwood on the loopback interface to protect their machines from this attack). OK, basically, this is an old problem DJB wrote about well over seven years ago. The solution is to randomize both the query ID and the source port; MaraDNS/Deadwood do this (and have been doing this since around the time of their first public releases that could resolve DNS queries) using a cryptographically strong random number generator (MaraDNS uses an AES variant; Deadwood uses the 32-bit version of Radio Gatun). (But CERT has no reply in their advisory from MaraDNS, so I'm not sure if this statement was made on the basis of just what is publically known, or if he was in fact in on the vendor notify list). -Jack [1] http://securosis.com/2008/07/08/dan-kaminsky-discovers-fundamental-issue-in-dns-massive-multivendor-patch-released/ [2] http://www.doxpara.com/?p=1162 [3] http://marc.info/?l=maradns-listm=121560639013865w=2 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Ben Laurie wrote: Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. Guess you need to tell Dan that - he seems to think he did discover it. Well, he does seem to credit quite a few people and companies on his own blog entry about the matter: http://www.doxpara.com/?p=1162 It does seem he would like an air of some mystery to exist though until he makes his presentation about the issue at Defcon - did he, himself, discover something new? We'll just have to wait, unless we go play with the BIND code ourselves. Regards, - johnk - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
+ John Kemp [EMAIL PROTECTED]: It does seem he would like an air of some mystery to exist though until he makes his presentation about the issue at Defcon - did he, himself, discover something new? We'll just have to wait, unless we go play with the BIND code ourselves. Unless he is merely blowing smoke, it would seem that he discovered some little twist that makes the known vulnerability much more easily exploitable than previously assumed. That would explain his statement: the patch fixes a well known vulnerability, and as a side effect stops the more serious attack, in effect making it hard to tell what is involved in that attack from reading the patch. - Harald - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Steven M. Bellovin wrote: On Wed, 09 Jul 2008 11:22:58 +0530 Udhay Shankar N [EMAIL PROTECTED] wrote: I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? Udhay http://www.liquidmatrix.org/blog/2008/07/08/kaminsky-breaks-dns/ I'm curious about the details of the attack. Paul Vixie published the basic idea in 1995 at Usenix Security (http://www.usenix.org/publications/library/proceedings/security95/vixie.html) -- in a section titled What We Cannot Fix, he wrote: With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all. So this seems to me to only be really true in a theoretical sense. Exploring the whole 32 bit space obviously requires well in excess of 4 GB of traffic, which is clearly a non-trivial amount to dump on your victim. According to other data, the fix in BIND is to: a) use random ports b) use a good PRNG so I'm beginning to suspect the issue is simply that the theory that it was easy to attack led to no effort being made to make it as hard as possible. And now it has. Obligatory crypto: the ISC web page on the attack notes DNSSEC is the only definitive solution for this issue. Understanding that immediate DNSSEC deployment is not a realistic expectation... The beauty of DNSSEC being, of course, that any answer that verifies can be trusted - so its of no interest who provided that answer. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
