Slashdot Mirror
Massive, Coordinated Patch To the DNS Released
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."
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.... 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.
Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.
My blog
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.
Here is the CERT advisory in a readable format.
http://www.kb.cert.org/vuls/id/800113
BTW, did they hold this for a Microsoft patch Tuesday?
-molo
Using your sig line to advertise for friends is lame.
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 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.
Except your Unix/Linux server is probably using BIND , and ISC has released a patch (and lots more information): http://www.isc.org/index.pl?/sw/bind/bind-security.php
Debian released 3 advisories:
bind9:
http://www.debian.org/security/2008/dsa-1603
bind8:
http://www.debian.org/security/2008/dsa-1604
glibc:
http://www.debian.org/security/2008/dsa-1605
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
Using your sig line to advertise for friends is lame.
... because djb recognized the vulnerability. it's even documented as such: http://cr.yp.to/djbdns/dns_random.html
djbdns consists of a separate server (tinydns) and resolver (dnscache).
Don't piss off The Angry Economist
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.
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
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?
Everybody else is being patched to the level of security that we djbdns users have always had. Not to be *too* smug, of course.
Don't piss off The Angry Economist
Senior sysadmins certainly should be able to program. Programmers only have to debug their own code, sysadmins have to debug everyone's code. :D But seriously, to properly debug problems you have to be able to work at all layers of abstraction, from hardware up to the application level; just sitting at one level of installing, applying updates, and rebooting to "fix" problems does not a sysadmin make.
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.
Those tend to be referred to as network and system engineers these days.
http://cr.yp.to/distributors.html
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.
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 and BIND 9.4.3b2; 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.
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.. :)
...an Englishman in London.
The advisory indicated two different scenarios and discussed specifically that section 2.2 (the advisory did not call it out by name). the flaw Kaminsky found he claims, is still possible even while addressing transaction ID guessing.
A good way to find out is to go directly to the CERT web site and have a look at the vulnerability note they're talking about. Link here, if you trust me =) http://www.kb.cert.org/vuls/id/484649/
Do not mock my vision of impractical footwear
[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.
From this posting: "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.
Laws do not persuade just because they threaten. --Seneca