Slashdot Mirror


The Backstory of the Kaminsky Bug

Ant recommends a Wired piece on the background story of the Kaminsky DNS bug and its (temporary) resolution, decreasing the odds of a successful breach from 1 in 2^16 to 1 in 2^32. We've discussed this uber-hole a number of times. Wired follows the story arc from before Kaminsky's discovery of the bug to his public presentation of it in Las Vegas.

2 of 122 comments (clear)

  1. Re:Do I not understand? by ArsenneLupin · · Score: 4, Informative

    So, uh... why not just turn off caching of everything besides the *ACTUAL* request?

    Actually, as far as I understood, the attack is making the information "appear" to be relevant. For instance, DNS may contain aliases (CNAMEs) that do not directly resolve in an IP address, but rather into another name.

    So, www.yourcompany.com may point to houdini.yourcompany.com, which itself resolves into 137.142.13.14.

    When a client queries for www.yourcompany.com, the DNS server not only answers that query, but "helpfully" supplies the second leg, in order to save one round-trip.

    Same thing with NS queries.

    So, all the perp has to do is have nothere.domain.com pretend to be a CNAME for www.domain.com, and "helpfully" supply a mapping from www.domain.com to an IP under your control. Because the "unsolicited" mapping appears to be relevant, the client DNS server will cache it.

  2. Powerpoint by mr100percent · · Score: 4, Informative

    Here's Kaminsky's powerpoint given at the Black Hat conference. (106 slides but thorough) This Wired article and the powerpoint is enough to make me panic. He literally broke the internet; unlock any website and spoof any logs. Now I see why there was so much panic in the article.