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

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

    1. Re:A possible downside by Ed+Avis · · Score: 2, Insightful

      It does sound like an issue. Suppose an authoritative server responds to a query with a TTL of five minutes. That means it must not change the record during the next five minutes. After one minute the domain owner makes some change. Okay, there will be a lag of four minutes before it fully takes effect. Fine. But what if a second request is received a minute after the change? The authoritative server has to know that it has a change queued up to take effect in three minutes' time, and serve a reply with a TTL of three minutes or less. Moreover, it has to reply with the old version of the record, which is now known to be out of date. So internally it needs to keep track of old and new versions for each change, and keep serving the old version until the last TTL of a previous reply to that version expires. I doubt that all the various DNS servers across the net do this.

      --
      -- Ed Avis ed@membled.com
  4. Re:Not the first time! by Anonymous Coward · · Score: 1, Insightful

    And if you used unit tests like a real developer you would had caught that simple error.

  5. 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
  6. poisonous disinformation and ignorance by mibh · · Score: 2, Insightful

    i know of forms of poison that do not involve the authority section at all.

    i know of servers with no BIND code inside that were poisoned by kaminsky.

    i know of valid configuration changes that depend on NS RRset replacement.

    is this a troll of some kind? as slashdot lead articles go, this one shows unusually high disinformation and ignorance.

  7. Re:Updating non-expired records? by tsalmark · · Score: 2, Insightful

    I don't think hacking every DNS server has ever been the solution of choice. Maybe updating your record and serial number, then reloading, if needed, the authoritative server. And the ones you don't control, well wait.