Slashdot Mirror


Kaminsky DNS Bug Claimed Fixed By 1-Character Patch

An anonymous reader writes "According to a thread on the bind-users mailing list, there is nothing inherent in the DNS protocol that would cause the massive vulnerability discussed at length here and elsewhere. As it turns out, it appears to be a simple off-by-one error in BIND, which favors new NS records over cached ones (even if the cached TTL is not yet expired). The patch changes this in favor of still-valid cached records, removing the attacker's ability to successfully poison the cache outside the small window of opportunity afforded by an expiring TTL, which is the way things used to be before the Kaminsky debacle. Source port randomization is nice, but removing the root cause of the attack's effectiveness is better."
Update: 08/29 20:11 GMT by KD : Dan Kaminsky sent this note: "What Gabriel suggests is interesting and was considered, but a) doesn't work and b) creates fatal reliability issues. I've responded in a post here."

2 of 120 comments (clear)

  1. Re:What about other DNS servers ? by larry+bagina · · Score: 5, Informative

    There is a small window of time when a malicious record could be cached by ANY DNS server. (Port randomization makes guessing the correct port to hit much harder) Bind (and only bind) has/had a huge fucking bug that opened that window of time.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  2. Re:A possible downside by Anonymous Coward · · Score: 5, Informative

    That's not how caches work. There is no guarantee that the authoritative server won't give out different responses until the TTL expires. The TTL just means that the resolver may cache the value for that duration. If the value changes during that time, the effect is just like when the server does DNS round-robin load balancing: This resolver uses a different value than other resolvers. Whether that is a problem depends on the validity of the resource, not on a server side decision to stick with an answer or to change it before the old value's TTL. When you change DNS records, you always keep the old resource up until you see only a low amount of requests to the old resource. There are way too many caches which ignore the server-defined TTL and use their own minimum TTLs.