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."
What about other DNS servers ? (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' ?
I call bullshit (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.
A possible downside (Score:4, 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.
Re:Not the first time! (Score:1, Insightful)
And if you used unit tests like a real developer you would had caught that simple error.
Re:A possible downside (Score:3, 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.
NOT a fix... (Score:5, 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.
Re:What about other DNS servers ? (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.
Re:What about other DNS servers ? (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.
poisonous disinformation and ignorance (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.
Re:Updating non-expired records? (Score:2, Insightful)