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

27 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 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:What about other DNS servers ? by Anonymous Coward · · Score: 3, Interesting

      Bind is effectively the reference implementation, so probably, or they made the same mistake at any rate. That's not surprising, this is a very subtle bug that requires knowledge of the Kaminsky attack to recognise. It's worth pointing out however that djbdns had source-port randomisation from the start as a defensive measure, and thus remained very resistant to this attack.

    3. Re:What about other DNS servers ? by gclef · · Score: 4, Informative

      No, this solution is basically breaking the DNS functionality that Kaminsky exploited. By design, the referral records were supposed to overwrite the cache (which some organizations do use). This patch breaks that.

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

    5. Re:What about other DNS servers ? by mrsbrisby · · Score: 3, Informative

      how come the same vulnerability is present on other DNS servers as well ?

      It isn't. djbdns for example, is not affected. I don't think maradns is affected either.

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

      Very likely.

      BIND has a very permissive license; most other DNS servers exist to facilitate lock-in with a particular vendor's stack, or to push some enhanced feature set, so they'd be considered foolish if they didn't copy BIND's source code where they could.

      If this is indeed not a protocol flaw,

      Well, I'm not sure it is unfair to call this a protocol flaw. Maybe a design flaw.

      BIND has resisted port randomization because "the RFC said so"- never mind that they wrote the RFC, and that no clients bother checking. Because it stopped spoofing attacks ten years ago, and it stops them today, most DNS servers- including those derived from BIND- do this.

      BIND also uses these very complicated credibility rules for determining if it can override existing cache-knowledge. This can presumably save one or two queries per dot, but surely it would be safer to only cache answers to questions that were asked. That is, by the way, what djbdns does.

      Most DNS spoofing attacks can also be solved by solving most blind spoofing attacks. There's a little reluctance to do so, because it makes things like DNSSEC largely obsolete for their intended audience. As a result, we see a lot of chest thumping and stomping in the temper tantrum. You can tell when you're about to get into one because they start by saying "If we just switched to DNSSEC by now, we wouldn't be having this problem."

      Of course, since BGP peers now route-filter everywhere on the internet (they didn't used to!), mandatory source filtering is a completely possible and realistic way to stop this and other similar problems...

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

    7. Re:What about other DNS servers ? by OriginalArlen · · Score: 4, Informative

      Dan's shot this nonsense down pretty comprehensively on his blog.

      --

      Everything I needed to know about life, I learnt from Blake's Seven
  2. Developer comments on the bug by Anonymous Coward · · Score: 4, Funny

    Ok! Ok! I must have, I must have put a decimal point in the wrong place
    or something. Shit. I always do that. I always mess up some mundane
    detail.

  3. Well let me just say by beakerMeep · · Score: 5, Funny

    (and I think for speak for everyone), this is how I feel about it:

    !

    --
    meep
  4. 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.

  5. Allegedly... by drmofe · · Score: 3, Interesting

    ....Paul Vixie is no longer allowed to commit code to BIND. Can this vulnerability be traced to code that he DID write originally?

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

    2. Re:A possible downside by photon317 · · Score: 3, Informative

      But that's not what the TTL is for in the first place. The TTL was not intended to mean "I will hold this record for this duration, ignoring any other updates in the meantime". It was meant to mean, "I will not under any circumstances remember this record any longer than this duration". The difference has practical implications for DNS operations.

      --
      11*43+456^2
  7. Server 2008 patch for this now out by Anonymous Coward · · Score: 4, Funny

    It's 570MB.

  8. Not getting much love in the mailing list by ccguy · · Score: 4, Funny

    I'm so bored that I actually read the post in the mailing list and all the replies in the thread.

    Just to be at the same time informative and to the point, the 7 replies so far have been as positive as this patch is in the linux kernel mailing list a few years ago.

  9. Reminds me of the story... by hanshotfirst · · Score: 5, Funny

    (Source unknown)

    A manufacturer had a problem with one of the older machines on their line. It shut down the line and held up production, costing many thousands of dollars in lost production. Since it was older equipment it was hard to find someone knowledgeable in repairing the machine, and nobody on-site knew what the problem could be. They found a technician with knowledge of the machine and hired him to come in and fix it.

    When the technician arrived on site he listened to the client's description of the problem, examined the machine, opened a panel, and turned a single screw. He restarted the machine and it was back to full function. The line was up and running and the manufacturer was happy.
    A week later the manufacturer received a bill for services: $1000. They called the technician and demanded an explanation - after all, they reasoned, he had only turned one screw to fix the problem. He agreed to re-bill, this time with itemized charges. The next bill contained two lines.

    Turning the screw... $1
    Knowing which screw to turn... $999

    --
    Why, oh why, didn't I take the Blue Pill?
  10. Re:OSS wins again by somersault · · Score: 4, Interesting

    This has more to do with an oversight in the DNS standard - doesn't have anything to do with any single implementation. Windows, Linux, and any other networked system that uses DNS are equally affected.

    Besides, it doesn't matter if your operating system is Open Source. You can write closed or open source software on any platform you want, and just because the source is available does not necessarily mean that bugs will be noticed and fixed. This situation just shows that even if there are no 'bugs' in an implementation of a standard, the original design may still be flawed.

    I haven't been following this situation very closely, so perhaps I'm a bit off with the details, but I'd be happy for someone to put me right if that's the case.

    Favouring cached DNS records seems to me to not be a spectacular idea for all situations. It depends on the length of the TTL setting on your DNS server though. I'm not sure what expiry time would be sensible for an ISP to use. You have to balance the fact that you want to up to date records with the amount of overhead that will be generated by all the DNS traffic.

    --
    which is totally what she said
  11. Re:Steve Jobs by El+Yanqui · · Score: 5, Funny

    Steve Jobs is alive and Slashdot isn't even covering it. This place blows.

    --
    Well, thanks to the Internet, I'm now bored with sex.
  12. 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
    1. Re:NOT a fix... by blueg3 · · Score: 3, Informative

      In cases where www.foo.com is not cached, DNS resolvers are vulnerable to the much more trivial attack of simply forging the answer www.foo.com IN A 66.6.66.6. Of course, they have to hope to guess the proper transaction ID in the first query, because if they fail, the proper answer will be cached.

      Poisoning an uncached name is fairly easy and doesn't require Kaminsky's trick. Kaminsky's trick relies on caching the answers to questions you didn't ask, rather than not caching them or using the cached answer over the uncached answer. I think you called this the "elephant in the room" at Usenix Security, even. :-)

  13. Meh. by Rob+T+Firefly · · Score: 3, Funny

    Ever since seeng this I don't trust that one character, Patch.

    --
    Slashdot Burying Stories About Slashdot Media Owned
  14. Re:Steve Jobs by bistromath007 · · Score: 3, Funny

    Forget that. Shouldn't we have regular updates on whether or not Charles Babbage is still dead? He's the father of computing itself, for fuck's sake!

  15. It was more than that. by certain+death · · Score: 3, Informative

    They stopped random UDP port use, and now use a static pool of UDP ports for queries. Note that they have come out with a P2 release that addresses a completely different issue that the first patch caused. I was able to essentially cause a DOS on a BIND server that was patched with P1 by sending more than 10,000 queries to the system. It ran out of usable UDP ports and puked. The same issue exists in the Windows patch, and especially on Windows 2003 SBS. There was way more than one line of code, or a single character changed.

    --
    "My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
  16. Re:No, it doesn't! by quantumplacet · · Score: 4, Informative

    yes, the whole point of this patch is to fix this problem. previously, if i successfully passed a bad record for safdsaus.example.com i could send glue records for www.example.com that would overwrite your cached record for www.example.com no matter what. with this patch i can only pass bad glue records if the ttl on your cached www.example.com record has expired. this gives an attacker a very narrow window during which they could mount this type of attack, likely making it not worth the effort.

  17. Kaminsky's rebuttal by buelba · · Score: 4, Informative

    Kaminsky has an interesting rebuttal here.