Kaminsky DNS Bug Claimed Fixed By 1-Character Patch 120
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."
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."
Re:What about other DNS servers ? (Score:5, Informative)
Re:Steve Jobs (Score:1, Informative)
is dead. And Slashdot isn't reporting it. I guess that are too busy with the idle section.
That would probably be because Steve Jobs is not dead [nzherald.co.nz], though that never stopped them before, given BSD's "untimely demise". ;)
Re:What about other DNS servers ? (Score:5, 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.
Re:Not the first time! (Score:3, Informative)
better change:
Remove the < *AND* don't use a hardcoded number, change to sizeof
Re:A possible downside (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.
Re:NOT a fix... (Score:4, 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. :-)
Re:A possible downside (Score:3, 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.
Re:A possible downside (Score:4, 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.
It was more than that. (Score:3, Informative)
Re:No, it doesn't! (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.
Re:What about other DNS servers ? (Score:4, Informative)
It isn't. djbdns [cr.yp.to] for example, is not affected. I don't think maradns is affected either.
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.
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...
Re:A possible downside (Score:3, Informative)
.
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.
Re:A possible downside (Score:3, 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.
Re:A possible downside (Score:3, Informative)
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.
Re:Not the first time! (Score:3, Informative)
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.
Kaminsky's rebuttal (Score:5, Informative)
Re:What about other DNS servers ? (Score:3, 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.
Re:What about other DNS servers ? (Score:3, Informative)
Re:What about other DNS servers ? (Score:5, Informative)