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

Comments

Not the first time!

[supernova_hq]

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

Re:Not the first time!

[jellomizer]

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

Allegedly...

[drmofe]

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

Re:What about other DNS servers ?

[Anonymous Coward]

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.

Re:OSS wins again

[somersault]

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.

Re:Not getting much love in the mailing list

[Nigel Stepp]

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.

Re:What about other DNS servers ?

[Anonymous Coward]

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