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

44 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 Anonymous Coward · · Score: 2, Interesting

      +1 Insightful

      This is what the DNS books I've read say happens. When I first started playing with DNS I was always surprised and could never explain why my updated records became active before the old record's TTL expired. Sounds like a bug that's been needing to be fixed for a long time now.

    8. Re:What about other DNS servers ? by wkcole · · Score: 2, Informative

      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' ?

      No.

      The /. description of that thread is inaccurate and the behavior of BIND in breaking trustworthiness ties (which are set up by RFC2181) in favor of apparently newer records is not a bug, but rather a behavior which has been operationally useful and normal for most of the history of DNS. If you look closely at Dan Kaminski's discussion of how he came to recognize the vulnerability, it becomes clear that he was using that normal behavior and put together all of the pieces of the attack from the fact that his experimental idea to enhance availability with spoofed DNS replies was working.

      With the caveat that I'm trusting the posts on bind-users rather than looking in depth at the code in question, it seems to me that this change would restrict the defined functionality of dynamic DNS, which to some degree relies on resolvers treating new records as new rather than as forged, even if the TTL of a cached record from an equivalently authoritative (apparent) source has not expired. The way DNS changes propagate in practice would be modified significantly by this, and people who have gotten away with poor planning of DNS changes in the past would be hit harder by that sloppiness if the behavior of nameservers (BIND *and* others) is switched from giving ties to the new data to giving ties to cached data.

      In the end, I think that there will need to be a new RFC on DNS extending RFC2181's discussion of cache/answer conflict resolution. IMHO the likely outcome of that will be a new model for conflict resolution that will make cache poisoning a bit harder while punishing authoritative servers for zones that either change a lot or are heavy spoofing targets with both load and a requirement of pedantic correctness. The only hope for resolving a conflict correctly would be to toss out every record between the root and the point of conflict and restart a recursive resolution of the conflicted names. That is a bit ugly, but not as ugly as simply switching the way the coin is flipped on cache/answer ties.

    9. Re:What about other DNS servers ? by OriginalArlen · · Score: 2, Informative

      No, you are mistaken; djbdns, MaraDNS (and all other conformant DNS servers, including the patched BIND) are vulnerable to the "ten hour attack", ie., the same attack run for ten hours rather than ten seconds. It just takes a bit longer to work because it has to hit the right port number out of the 65K range.

      --

      Everything I needed to know about life, I learnt from Blake's Seven
    10. 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. Not the first time! by supernova_hq · · Score: 2, Interesting

    This is not the first time a huge security vulnerability was fixed by changing a single character!

    From what I remember, the SSL vulnerability we saw a while ago was caused by a single excess comment mark (well, maybe two if it was a double forward slash

    1. Re:Not the first time! by jellomizer · · Score: 2, Interesting

      There are a lot of bugs fixed by changing 1 character... It is a very common occurrence. Either you comment out a feature that isn't needed but causing a problem. Or change a default variable or a constant to a different value.
      Eg origional code (Just making it up on the fly) of a possible security hole bug:

      char x[9];
      // x is populated by a char* variable
        for (register int i=0; i <= 9; i++) {
      //doing some stuff on x[i]
        }

      Now anyone with any C experience will realize that we have the possibility of an overflowed buffer. Now what is the fix, I see 2 of them that can fix the problem with 1 character change.
      I could change = to by removing the =
      or I could change 9 to 8 in the for loop.
      Chances are for the most cases this code may go missed for a while, and the program will run great for years. Perhaps the char* input command limited they keyboard to 8 letters forcing the 9th to be null all the time. Then the code was changed to work for the web and its keyboard limit code was removed with a QuaryString value, without the check or the check stupidly done in Javascript or HTML maxlength. But still it is a security consern and can be fixed with 1 character and if you look at any CS 101 class you will see how common this error is. Espectially if they swap back and forth from VB to C

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    2. Re:Not the first time! by sqlrob · · Score: 2, Informative

      better change:

      Remove the < *AND* don't use a hardcoded number, change to sizeof

    3. Re:Not the first time! by locofungus · · Score: 2, Informative

      ..change to sizeof...

      Which will return the size of a char * (pointer to character) on your system (typically 4 bytes), _not_ the length of the array. There is no way in C to get the length of an array after it's been allocated. Arrays are 'stupid' chunks of memory, not objects with properties.

      Huh?


      char x[9];
      printf("%d\n", (int)sizeof x);

      will print 9 exactly as required.

      There are a handful of cases where arrays do not decay to pointers. This is one of them.

      Tim.

      --
      God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
  4. 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
  5. 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.

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

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

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

      thank you!
      A TTL is not a promise to never change the record. A true authoritative source can change and push new information. A TTL is an amount of time that a cached record can live before the holder of the cache needs to check back for new information, which is usually not changed.

    4. 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
    5. Re:A possible downside by QuietLagoon · · Score: 2, Informative
      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 :)
      .

      TTL does specify the Time To Live for a cached record before it is no longer considered to be valid.

      TTL does not specify the length of time that changes are not allowed.

    6. Re:A possible downside by mrsbrisby · · Score: 2, Informative

      No, a true authority cannot push new information.

      They would have to know all of the caches in order to push the changes to them, and since caches can cache for caches, it's unrealistic that a normal site could know this, and unlikely that a specially designed site would.

      The cache should not cache answers to questions it didn't ask, and that includes new authorities for the domain.

    7. Re:A possible downside by mrsbrisby · · Score: 2, Informative

      But, there are cases of things like stealth masters that do keep track of all of its slaves, and these can tell the slaves to come look for new information. Not allowing updates to the slaves because of TTLs would create a non-needed time gap in propagation.

      That's a terrible reason to allow such a large security hole.

      You should have to list all of your ignore-ttl-from hosts, and src-filter communication to those sites before you should be allowed to do this.

      That said, you could also use some other communication channel- such as the master sshing over to the cache and flushing the cache. Certainly that's safer and easier.

  8. Server 2008 patch for this now out by Anonymous Coward · · Score: 4, Funny

    It's 570MB.

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

    1. Re:Not getting much love in the mailing list by Nigel+Stepp · · Score: 2, Interesting

      Ha! I feel like that is the same guy who wrote a text editor that runs in ring 0 or something and halts multitasking.

      Anyone remember that guy? There was a huge usenet fight about it on some linux newsgroup in the 90s.

      Anyway, he had exactly the same reasoning style.

      --
      4096R/EF7BAFA6 79E1 DF98 D09D 898F 9A11 F6F0 DDDC 23FA EF7B AFA6
  10. 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?
  11. 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
  12. Re:No, it doesn't! by CaraCalla · · Score: 2

    It is indeed an issue: The injected record is trusted because it orgiginates from example.com, but the evil bits are in the glue record, which goes ahead hijacking the www.example.com record. Without really knowing bind, I assume the patch does not work in that case.

  13. 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.
  14. 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. :-)

  15. 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
  16. 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!

  17. Re:Steve Jobs by Anonymous Coward · · Score: 2, Funny

    Maybe we should have a Charles Babbage status page a bit like this one:
    Abe Vigoda

  18. 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
  19. 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.

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

    Kaminsky has an interesting rebuttal here.

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

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