Slashdot Mirror

← Back to Stories (view on slashdot.org)

Kaminsky DNS Bug Claimed Fixed By 1-Character Patch

Posted by kdawson on from the but-it's-the-right-character dept.

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."

6 of 120 comments (clear)

  1. What about other DNS servers ? by neonux · · Score: 5, Insightful

    If this is indeed not a protocol flaw, how come the same vulnerability is present on other DNS servers as well ?

    Do they all use the same code from BIND for this particular 'feature' ?

    --
    @neonux
    1. Re:What about other DNS servers ? by B'Trey · · Score: 5, Insightful

      That seems accurate to me. After all, what happens when a DNS record gets updated? With the new behavior, you won't see the change until your cached record expires. That may be preferable to a gaping security hole which lets attackers poison your cache, but I don't think it's accurate to call the issue a bug in BIND. I believe BIND was working as intended to allow updated records to overwrite older ones.

      --

      "The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.

    2. Re:What about other DNS servers ? by More+Trouble · · Score: 5, Insightful

      After all, what happens when a DNS record gets updated? With the new behavior, you won't see the change until your cached record expires.

      You don't see that update until the TTL expires. That's why there's a TTL. If you're planning to make a change, lower the TTL well in advance to allow the new TTL to propagate.

  2. I call bullshit by Anonymous Coward · · Score: 4, Insightful

    Updating a cache with new data when the source data changes before the cached copy is a bug?

    The "root cause" is being able to fake being the correct source of the data being overwritten, NOT the ability to refresh a cached copy.

    And AFAICT, the ability to falsify data sources remains a FUNDAMENTAL flaw in DNS.

  3. A possible downside by js_sebastian · · Score: 3, Insightful

    From one of the mails of the guy who made this proposal:

    What's the downside to my patch ? I guess we are now holding an
    authoritative server to the promise not to change the NS record for
    the duration of the TTL, which is kinda what the TTL is for in the
    first place :)

    I wonder if this is an issue. Otherwise it seems Kaminsky may really have missed the point.

  4. NOT a fix... by nweaver · · Score: 4, Insightful

    This is NOT a fix to the root problem of the Kaminski vulnerability.

    The root problem is the cases where athority/additional/unasked-answers are accepted, and there are plenty of variants this "patch" does not affect. EG.

    Answer:
    whatever.foo.com CNAME www.foo.com
    www.foo.com A 66.6.66.6
    Authority:
    (usual goop).

    If www.foo.com is not yet cached (and often even if it is), this will set it as a Kaminski variant.

    --
    Test your net with Netalyzr