Slashdot Log In
Kaminsky DNS Bug Claimed Fixed By 1-Character Patch
Posted by
kdawson
on Fri Aug 29, 2008 07:14 AM
from the but-it's-the-right-character dept.
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."
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."
Related Stories
[+]
Massive, Coordinated Patch To the DNS Released 315 comments
tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."
[+]
Technology: DNS Flaw Hits More Than Just the Web 215 comments
gringer writes "Dan Kaminsky presented at the Black Hat conference in Las Vegas on Wednesday, and said that the DNS vulnerability he discovered is much more dangerous than most have appreciated.
Besides hijacking web browsers, hackers might attack email services and spam filters, FTP, Rsync, BitTorrent, Telnet, SSH, as well as SSL services. Ultimately it's not a question of which systems can be attacked by exploiting the flaw, but rather which ones cannot. Then again, it could just be hype.
For more information, see Kaminsky's power point presentation." Update: 08/07 19:48 GMT by T : There's also an animation of the progress of the patch.
[+]
DNS Poisoning Hits One of China's Biggest ISPs 86 comments
Support Code writes "ZDNet's Zero Day blog is reporting that a DNS server of one of China's largest ISPs has been poisoned to redirect typos to a malicious site rigged with drive-by exploits. The DNS poisoning attacks are affecting customers of China Netcom (CNC) and are using a malicious iFrame to launch exploits for known vulnerabilities in RealNetworks' RealPlayer, Adobe Flash Player and Microsoft Snapshot Viewer. In this interview with CNet, Dan Kaminsky confirms that attacks are definitely going on in the field."
Firehose:Kaminsky DNS Bug Fixed by Single Character Patch? by Anonymous Coward
[+]
DNS Inventor Tackles Flaw 101 comments
nk497 writes "Dr Paul Mockapetris is looking to fix the flaws in the Domain Name System he helped invent. 'It was never meant to be the only security mechanism for naming data on the internet, but was intended for additional security measures to be added to it later.' The flaws, first uncovered by security researcher Dan Kaminsky over the summer, lets attackers redirect genuine URLs to malicious ones — a problem Mockapetris believes could be solved using digital signatures."
[+]
Technology: Kaminsky Bug Options Include "Do Nothing," Says IETF 80 comments
netbuzz writes "Meeting in Minneapolis this week, the Internet engineering community is debating whether to aggressively fashion and apply fixes for the so-called Kaminsky bug in the DNS discovered this summer, or to simply let its threat stand as motivation for all to move with greater speed toward DNSSEC, which is considered the best long-term security solution. Problem with the latter approach is that DNSSEC has been in the works for a decade already, no one is confident it will be universally embraced, and the Kaminsky flaw is causing real problems today.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
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' ?
Re:What about other DNS servers ? (Score:5, Informative)
Parent
Re:What about other DNS servers ? (Score:5, Informative)
Parent
Re: (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.
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.
Parent
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.
Parent
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.
Parent
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...
Parent
Developer comments on the bug (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.
Well let me just say (Score:5, Funny)
!
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.
Allegedly... (Score:4, Interesting)
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: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.
Parent
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.
Parent
Server 2008 patch for this now out (Score:4, Funny)
It's 570MB.
Not getting much love in the mailing list (Score:5, Funny)
Just to be at the same time informative and to the point, the 7 replies so far have been as positive as this patch [iu.edu] is in the linux kernel mailing list a few years ago.
Reminds me of the story... (Score:5, Funny)
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
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: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. :-)
Parent
Meh. (Score:4, Funny)
Kaminsky's rebuttal (Score:5, Informative)
Re:OSS wins again (Score:5, 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.
Parent
Re:Steve Jobs (Score:5, Funny)
Parent
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.
Parent