Massive, Coordinated Patch To the DNS Released 315
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."
not that big of a problem (Score:5, Informative)
I used to run a DNS hosting company. Fortunately, this error only affects caching resolvers, since it is yet another example of cache poisoning. There have been (and continue to be) hundreds of cache poisoning exploits over the years. This one is fairly technical and would require significant expertise to execute in a timeframe (ie: before everyone patches up) to cause harm. I don't know about you,but if someone started flooding my servers with thousands of response regords in hopes of guessing a transaction ID, my iptables config would block them in a heartbeat.
this is not the kind of security problem that should cause people's heart to skip a beat. your average malware worm is much worse.
dan has written an article on a javascript attack that can compromise a home router [google.com].... that's probably far worse - in terms of real damage (ie: bot creation, personal data stolen)
in sum... run yum update.... then don't worry about it.
DJBDNS not affected. (Score:5, Informative)
Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.
Reverse Engineering? (Score:5, Informative)
From the summary-
His DNS tester is submitting a DNS check that it knows will be relayed, and then monitoring if the upstream check (it is intentionally doing lookups against a DNS server it controls) consistently uses the same source port. If it does, hypothetically an attacker could send "response" packets in concert with the original request, poisoning the cache.
I would guess that the patch makes the DNS server randomize the nonce when relaying DNS requests.
I know nothing about this, but that's my super-l33t-hacker assumption from looking at it for 10 seconds.
CERT advisory in readable format: (Score:4, Informative)
Here is the CERT advisory in a readable format.
http://www.kb.cert.org/vuls/id/800113 [cert.org]
BTW, did they hold this for a Microsoft patch Tuesday?
-molo
Nature of the attack (Score:5, Informative)
It's reasonably obvious from the CERT advisory how an attack would work. The CERT advisory tells us that the vulnerable systems are ones where the 16-bit DNS transaction ID and the 16-bit port number for a transaction are not randomly chosen. The CERT advisory also tells us that the attacker must be able to spoof IP addresses, that is, they must not be behind some ISP with egress filtering. CERT also tells us that it's a DNS poisoning attack.
So it looks like a form of this attack documented in 2003 [net-security.org] at "Cache Poisoning using DNS Transaction ID Prediction". Back in 2003, it took a large number of packets to make this attack work, and even then it wasn't reliable. But there may be a more cost-effective attack strategy if you know how the DNS server assigns transaction numbers and ports.
The fundamental problem comes from 1) the fact that source IP addresses can be forged, and 2) the DNS transaction ID, at 16 bits, is far too short to be considered a useful random key. Any key with security implications should be at least 64 bits and be generated by a crypto-grade random number generator.
Re:More independent verification needed (Score:2, Informative)
Debian advisories.. glibc stub resolver effected! (Score:5, Informative)
Debian released 3 advisories:
bind9:
http://www.debian.org/security/2008/dsa-1603 [debian.org]
bind8:
http://www.debian.org/security/2008/dsa-1604 [debian.org]
glibc:
http://www.debian.org/security/2008/dsa-1605 [debian.org]
Bind9 now contains a port randomization, which can require firewall rule changes.
Bind8 is now considered deprecated and the advisory recommends upgrading to bind9. There is no patch for bind8.
The glibc stub resolver is also vulnerable, and there is no patch yet. The recommended workaround is to install bind9 as a caching resolver and point /etc/resolv.conf at localhost.
In short, this is a big mess.
-molo
djbdns apparently not affected (Score:5, Informative)
... because djb recognized the vulnerability. it's even documented as such: http://cr.yp.to/djbdns/dns_random.html [cr.yp.to]
Re:Any name server? (Score:3, Informative)
djbdns consists of a separate server (tinydns) and resolver (dnscache).
Re:More independent verification needed (Score:3, Informative)
Do you really have your firewall restricted in such a way that UDP packets are only allowed through if they come from specific ports?
In other words, do you care if a query to an external DNS server comes from port 15875 or port 15876 on a machine in your behind-the-firewall network? Likewise, do you care if incoming DNS queries to your DNS server come from port 28410 or port 28411 on Comcast's DNS server?
Since it's currently random (but fixed at startup of the server) in some DNS implementations, this shouldn't affect anything for 99.99% of people. Any sysadmin who sets up firewall rules that were so stringent as to assume a source port for a protocol that doesn't require a specific source port should have to deal with the trouble their stupidity caused.
Bad summary including a Word document?? (Score:2, Informative)
What a terrible summary. What would be really useful and news worthy would be a link to a web page with some information about the vulnerability. The links in the summary included: 1) a WORD DOCUMENT? WTF? 2) a PDF, 3) a podcast?? WTF? and 4) a link to a slashdotted DNS checker. How about a link to the CERT vulnerability web page which describes the problem?
http://www.kb.cert.org/vuls/id/800113 [cert.org]
Now THAT would have been much more useful. Do people who work as sysadmins actually have time to sit around listening to a podcast? Especially when there are DNS servers to patch?
Re:DJBDNS not affected. (Score:2, Informative)
IPV6 patch for DJBDNS [www.fefe.de]
Personally, I have no need for it or the IXFR functionality at this point.
However, my understanding is that BIND's IXFR implentation breaks if you use hand-written or tool-generated zone files.
Re:Any name server? (Score:5, Informative)
Everybody else is being patched to the level of security that we djbdns users have always had. Not to be *too* smug, of course.
Re:More independent verification needed (Score:3, Informative)
Job titles in our industry have always been a bit hazy, though. Perhaps the confusion arises because of a distinction some people make between a system administrator and an MIS or IT person? I wouldn't call the guy helping the sales droids with their windows machines a sysadmin - even though a sysadmin is capable of that of course. The sysadmin is the person running the critical infrastructure of the company such as firewalls, routers and web/file/mail/dns/cvs/development/testing/production servers.
Re:More independent verification needed (Score:3, Informative)
Those tend to be referred to as network and system engineers these days.
Re:Let the DJBing begin! (Score:4, Informative)
http://cr.yp.to/distributors.html [cr.yp.to]
As of December, the software is in the public domain. No licensing issues. If you would like to take on a distribution that has been patched, please feel free.
DJBDNS actually IS superior. It is lighter weight and more secure. And it has addressed this issue as best you can for more than 5 years.
Re:The Death of BIND (Score:5, Informative)
How in the world did you manage to get hold of the patches, test them, and deploy a competing product on a 90,000+ zone installation in the two hours between the patch's public release and your post? That's... really fast work.
Out of curiosity, what version of BIND were you running prior to the change, and on what OS/hardware?
It is true--and we acknowledged in the release announcments--that the initial security patches (9.3.5-P1, 9.4.2-P1, 9.5.0-P1) cause a significant performance hit on heavily-loaded systems.
There are further code optimizations that get performance roughly back to baseline, but we felt they were too extensive to release without putting them through a beta cycle.
Two beta releases, with the enhanced performance code, were published at the same time as the patches: BIND 9.5.1b1 [isc.org] and BIND 9.4.3b2 [isc.org]; you can grab them now (um, for values of "now" that include "very soon"; one of our 10G fiber links picked an unfortunate moment to fail).
The remaining beta, BIND 9.3.6b1, will be released in a few days, because five releases at one time was already enough to juggle.
Re:So give a layman explanation (Score:5, Informative)
Read the diffs to BIND and work it out. They're only hiding things from the bad guys to give you a few more hours window to implement the patches.. :)
Re:Prior Art (Score:3, Informative)
Re:So give a layman explanation (Score:4, Informative)
Re:Sinisterness (Score:5, Informative)
[This is Dan Kaminsky]
Er, you know you use DNS to retrieve web pages, right?
So I just watch how you retrieve my web page, and synthesize content based on the Port/TXID patterns you request my page with.
No code. Just script. And then I tell you whether you need to install a patch from your own vendor. It's not too complicated.
It's noted in the advisory. (Score:4, Informative)
From this posting [doxpara.com]: "DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use."
But I'm sure his acting like a jerk still means that nobody should ever take his criticisms of software design seriously. Heck, the BIND folks didn't, and it's not like people are going to stop using BIND.