Login  |  Register  |  Contact

Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released

Today, CERT is issuing an advisory for a massive multivendor patch to resolve a major issue in DNS that could allow attackers to easily compromise any name server (it also affects clients). Dan Kaminsky discovered the flaw early this year and has been working with a large group of vendors on a coordinated patch.

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.

Dan asked for some assistance in getting the word out and was kind enough to sit down with me for an interview. We discuss the importance of DNS, why this issue is such a problem, how he discovered it, and how such a large group of vendors was able to come together, decide on a fix, keep it secret, and all issue on the same day.

Dan, and the vendors, did an amazing job with this one. We've also attached the official CERT release and an Executive Overview document discussing the issue.

Executive Overview (pdf)

CERT Advisory (link)

Update: Dan just released a "DNS Checker" on his site Doxpara.com to see if you are vulnerable to the issue. Network Security Podcast, Episode 111, July 8, 2008

And here's the text of the Executive Overview:

Fixes Released for Massive Internet Security Issue

On July 8th, technology vendors from across the industry will simultaneously release patches for their products to close a major vulnerability in the underpinnings of the Internet. While most home users will be automatically updated, it's important for all businesses to immediately update their networks. This is the largest synchronized security update in the history of the Internet, and is the result of hard work and dedication across dozens of organizations.

Earlier this year, professional security research Dan Kaminsky discovered a major issue in how Internet addresses are managed (Domain Name System, or DNS). This issue was in the design of DNS and not limited to any single product. DNS is used by every computer on the Internet to know where to find other computers. Using this issue, an attacker could easily take over portions of the Internet and redirect users to arbitrary, and malicious, locations. For example, an attacker could target an Internet Service Provider (ISP), replacing the entire web -- all search engines, social networks, banks, and other sites -- with their own malicious content. Against corporate environments, an attacker could disrupt or monitor operations by rerouting network traffic traffic, capturing emails and other sensitive business data. Mr. Kaminsky immediately reported the issue to major authorities, including the United States Computer Emergency Response Team (part of the Department of Homeland Security), and began working on a coordinated fix. Engineers from major technology vendors around the world converged on the Microsoft campus in March to coordinate their response. All of the vendors began repairing their products and agreed that a synchronized release, on a single day, would minimize the risk that malicious individuals could figure out the vulnerability before all vendors were able to offer secure versions of their products. The vulnerability is a complex issue, and there is no evidence to suggest that anyone with malicious intent knows how it works.

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses. Unfortunately, due to the scope of this update it's highly likely that the vulnerability will become public within weeks of the coordinated release. As such, all individuals and organizations should apply the patches offered by their vendors as rapidly as possible.

Since not every system can be patched automatically, and to provide security vendors and other organizations with the knowledge they need to detect and prevent attacks on systems that haven't been updated, Mr. Kaminsky will publish the details of the vulnerability at a security conference on August 6th. It is expected by this point the details of the vulnerability will be independently discovered, potentially by malicious individuals, and it's important to make the specific details public for our collective defense. We hope that by delaying full disclosure, organizations will have time to protect their most important systems, including testing and change management for the updates. Mr. Kaminsky has also developed a tool to help people determine if they are at risk from "upstream" name servers, such as their Internet Service Provider, and will be making this publicly available.

Home users with their systems set to automatically update will be protected without any additional action. Vendor patches for software implementing DNS are being issued from major software manufacturers, but some extremely out of date systems may need to updated to current versions before the patches are applied. Executives need to work with their information technology teams to ensure the problem is promptly addressed.

There is absolutely no reason to panic; there is no evidence of current malicious activity using this flaw, but it is important everyone follow their vendor's guidelines to protect themselves and their organizations.

—Rich

Previous entry: Mozilla Project In Open Document Format | | Next entry: Dark Reading Column: Attack Of The Consumers (And Those Pesky iPhones)

Comments:

If you like to leave comments, and aren't a spammer, register for the site and email us at info@securosis.com and we'll turn off moderation for your account.

By US-CERT: Multiple DNS Implementations Vulnerable t  on  07/08  at  12:03 PM

[...] of the Cache Poisoning vulnerabilities in several DNS deployments (posted yesterday via Securosis). This is a highly critical issue, that apparently can only be overcome with a DNSSEC [...]

By Othello  on  07/08  at  12:31 PM

Steve O,

ZoneAlarm at one time may have been a good product, but I’‘m sorry, it senselessly throttles back your connection, but maybe that’s because I use the free (cheap) one.  Anyway, I digress; yes, there is a true potential for some real problems with this "new" hole in the DNS protocol.  And yes, if we (developers) all stuck to the RFCs (or even just wrote decent, concise, optimized code) when writing new and inventive code, our world would be perfect. But let’s face it, developers are about as lazy as it gets these days, everyone thinks that hardware is pretty much free, and Execs. allow them to open up these "holes" via terrible decision making. I say, let’s get back to basics, do the right thing, and write the code the way you _know_ it should be, but I live in a perfect world .

Now the "secret" is out, let’s just get together and fix this nonsense (another $0.02 worth).

Oh, and "Just About", when were RFCs about money?  I understand that you are from Brazil (or so it seems) but why all the yelling?

By Subnets.ru blog » Blog Archive » Фу  on  07/08  at  12:56 PM

[...] Каминский (Dan Kaminsky) обнаружил критическую уязвимость в принципе работы большинства [...]

By Kritische DNS Lücken erzeugt Updatewelle | adminl  on  07/08  at  01:43 PM

[...] Also, Updates einspielen und weiter die Ohren und Augen offen halten. Weitere Infos gibt es unter CVE-2008-1447 und securosis.com. [...]

By cjk  on  07/08  at  01:55 PM

@"Shamgar":
djbdns is said to use the kernel-level UDP port randomization—in case of Linux, the patch has gone into v2.6.24.


@"Just About":
I agree. Far too many RFCs have far too many "SHOULD" or "MAY" and should (oops!) have much more stricter semantics; it’s either "MUST" or "MUST NOT" and deviations from the RFC (given that the RFC is actually sane) MUST be rejected.

By DNS İçin Ciddi Bir Yama Yayınlandı : Doctus Ha  on  07/08  at  04:01 PM

[...] şirketlerle koordineli gizli bir çalışma başlattı. Çalışmaya 81 sağlayıcı katıldı ve yama sonunda tamamlanarak 8 Temmuzda [...]

By Martyn Thomas  on  07/08  at  04:06 PM

If this is the patch released by MS today for Win XP, I lost DNS connectivity after installing it and rebooting. ipconfig looked OK. Net Diagnostics couldn’‘t trace the problem. I could talk to my network router and it could see the internet but nothing got through the whole path. A second reboot of the XP machine restored connectivity.

By An Astonishing Collaboration : DoxPara Research  on  07/08  at  04:19 PM

[...] has details up, and there’s a full-on interview between myself and Rich Mogull up on Securosis.  For the non-geeks in the audience, you might want to tune out here, but this is my personal blog [...]

By me  on  07/08  at  04:26 PM

http://doxpara.com/

Not Found

The requested URL /printme.html was not found on this server.

By technichristian.net » Blog Archive » F  on  07/08  at  04:45 PM

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

By Dave J.  on  07/08  at  04:53 PM

Everyone using ZoneAlarm w/ the firewall set on High for the Internet Zone Security has been shut off the internet. The only fix is to set to a more vulnerable Medium setting or uninstall the MS patch. Most all seem to be uninstalling the MSKB951748 patch.

By commenter  on  07/08  at  04:54 PM

I just read the comments here.

How come there’s so many arrogant blowhards on the internets?

By Vulnerabilidade no DNS | Israel Junior  on  07/08  at  05:01 PM

[...] lwn.net: Dan Kaminsky has found a flaw in the design of DNS that can allow cache poisoning as an article at Securosis.com details. This has lead to a CERT advisory as well as a coordinated release of patched DNS servers from all [...]

By 爷爷  on  07/08  at  05:10 PM

草你妈的,你就鸡巴装逼,
要么公布,要么啥也别说,
犊子

By   Faille DNS : Cache Poisoning par   on  07/08  at  05:31 PM

[...] Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released | securosis.com [...]

By Avatar  on  07/08  at  06:10 PM

What about <a href="http://isc.sans.org/diary.html?storyid=4693" rel="nofollow">this post</a> at the Internet Storm Center?  <a href="http://www.sans.org/reading_room/whitepapers/dns/1567.php" rel="nofollow">Ian Green wrote about this in 2005 in his GSEC whitepaper</a>.

By JimBo  on  07/08  at  06:22 PM

This is Bollocks

By fugdabug  on  07/08  at  06:33 PM

I don’‘t think it is that simple.  This is an old problem, and there is more to the soup than the ‘‘sky is falling’’ approach. No I don’‘t think a ‘‘scare’’ is what we need.  We need more people on computers that are aware of the ‘‘how it works’‘, and less of the ‘‘I wanna push the funny buttons-’’ type of people.  Which means a more educated community of users.  WE ALSO NEED LESS MONOPOLY IN THE OS DEPT.!  Everybody knows, over-specialization leads to extinction!

By ds  on  07/08  at  06:46 PM

>>
WE ALSO NEED LESS MONOPOLY IN THE OS DEPT.! Everybody knows, over-specialization leads to extinction!
<<

The irony of this being posted in a message that speaks about the presence of the exploit in multiple vendor’s code.  This isn’‘t a vendor created problem, it is inherent in the DNS protocol.

By Allen Baranov  on  07/08  at  06:50 PM

Having read the comments and checked out the site mentioned in the blog I have the following theory:

1. I connect to vulnerable DNS Server and query my very own domain. I note what the UDP source port is.

2. I connect to the DNS Server again ASAP and query another of my very own domains. I note what that UDP source port is.

3. Assuming they are close together I do a query of "microsoft.com" or some such and send a UDP reply to the server with a bogus IP address. I could probably send 20 replies so that I get the correct port.

4. Cache is poisoned.

Am I missing anything?

By The biggest bug of the Internet is now solve! &laq  on  07/08  at  07:07 PM

[...] has details up, and there’s a full-on interview between myself and Rich Mogull up on Securosis.  For the non-geeks in the audience, you might want to tune out here, but this is my personal blog [...]

By d0t  on  07/08  at  07:39 PM

Allen Baranov <———-  This guys on the right track ;)

I wish the "exploit" could have lasted longer :( *sigh*

d0t

By Steve Pinkham  on  07/08  at  07:47 PM

Allen Baranov:
Yes.
There is a 16 bit nonce that you also don’‘t know, so you have to send an average of 2^16/2 = 32768 packets before the real response gets back.
At ~100 Bytes a packet, that’s 3MB you need to send out in .03-1 second or so before the DNS query response.  If you can delay or drop the response, you’‘re golden.
The "birthday attack" discovered in 2002 drops the amount of traffic needed to be sent significantly, if the DNS server sends multiple queries for the same data from the same port.
It can take the 32768 responses for %50 chance of exploit down to 300, or 30KB or responses, and 20KB of requests(usually smaller). 50KB of traffic is nothing these days, and any resolver which is still vulnerable to the birthday attack can be owned without much fuss. Many of the servers have been patched against this for a long time now.
I have my slides from a talk I gave on DNS security and DNSSEC last year, which covers all this in more detail.
http://www.mavensecurity.com/documents/J9-DNS-Security-handouts-2008-02-17.pdf
I do wonder what if anything Dan has to add to the already known brokeness of DNS. Using multiple hosts to do the flooding? Been done. Special ordering of the packets for best results? Donno, but the sky was already falling before Dan opened his mouth, but now we get to talk about it anyway ;-)
The question is is anything going to get fixed this time around, or will we be living with broken DNS for another 10 years before we actually fix the real problem of 16bit nonce w/ possible 15-16 bit source port?

By Steve Pinkham  on  07/08  at  08:05 PM

Great explanation of the problem here, showing differing size of secure nonces used in and out of DNS:
http://www.matasano.com/log/1089/dan-kaminsky-could-have-made-hundreds-of-thousands-of-dollars-with-this-dns-flaw/

Note DNS ID’s are WAY undersized..
Unfortunately 99% of our problems could be solved with a 128 bit or so DNS nonce, but instead of the simple fix we have an over-engineered DNSSEC standard that’s taken more then 10 years to get anywhere (and it’s still not widely deployed at all in the US).
Now don’‘t get me wrong, DNSSEC is the proper long term secure fix. However we should have had a "good enough" fix in the form of longer transaction ID 10 years ago which would solve everything but the man in the middle problem.

By rsp  on  07/08  at  10:50 PM

Wouldn’‘t the existence and availability of the "DNS Checker" point to the nature of the vulnerability?  Couldn’‘t someone snoop to see what it’s doing?

Name:

Email:

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: