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."
http://www.doxpara.com/
Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.
Sweet!
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.
Still, it's not exactly like you clicked a banner with a lame attempt at a bouncing, fake window telling you your DNS software was in immediate need of a fix and that this combination patch and shopping buddy would fix it.
Your mind is clear / The things that you fear / Will fade with how much you / Believe what you hear
Because it isn't 1912, and we aren't on the Titanic. They can say with reasonable confidence that it's difficult to find the underlying issue, but nothing is hackproof, or sinkproof, or lameproof.
- oZ
// i am here.
I'm (sort of) a native German speaker, in which "DNA" is abbreviated "DNS" ("DesoxyribonukleinsÃure" with "sÃure" being "acid").
Needless to say, my first impression of the headline was way more futuristic than what is there.
Power corrupts the few, while weakness corrupts the many.
> Microsoft's own DNS implementation is also affected
Did anyone else notice that today is Tuesday?
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.
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.
...is to sign the root and deploy DNSSEC.
Unfortunately that's politically non-expedient. But now that this vulnerability is out there, maybe the political will can at last materialize.
The second-best solution is to deploy DNSSEC using DNSSEC Lookaside Validation (which means you get trust anchors from some other known site, not from the root zone). And that's available now.
The worst thing about DNSSEC is it's too damn complicated at present; there needs to be the equivalent of "one-click" zone signing. ISC (and others) are working on getting us closer to that.
The third-best solution is what's been done today. We just made it a lot harder to exploit the vulnerability--typically about 16000 times harder, depending on your configuration. There's a difference between "harder" and "impossible" though.
Uhm...
DJB-ware is now in _public_ _domain_. That's even more liberal than the BSD license.
So, update your /etc/hate file with newer facts...
... because djb recognized the vulnerability. it's even documented as such: http://cr.yp.to/djbdns/dns_random.html
So you are insinuating that all system admins also have to be programmers? There are plenty of people with the skills to set up, maintain, and secure (properly) systems of all kinds (*nix, Windows, Macs, Cisco equip) who are NOT programmers. Some people are not cut out to be programmers, but are quite capable outside of that realm...
it is good to have a sysadmin who can write programs in binary
I'd like to meet one of these sysadmins. I've written system stuff in C and other stuff in Pascal, C++ and Perl over the years but the guy that can write direct to binary must really know his stuff. Just think, his keyboard only needs two keys!
Right... How many otherwise competent sysadmins do you know who can't C code? I've known plenty. Usually the good coders get jobs as coders, rather than as sysadmins.
http://outcampaign.org/
People with that amount of expertise will hardly be challenged by sysadmin position. And without a challenge you'll get bored. As such, you'll never find people with such high qualifications in sysadmin position.
A sysadmin of course needs to know his stuff, and especially a unix sysadmin should be able to read C code and get the basics (and have extensive knowledge in scripting languages).
But i doubt that understand the gritty details how bind works (or reading a DNS packet with just a hex editor) is something that can be expected from a sysadmin.
But i also might just be defending my lack of knowledge, so beware :)
I help admin one of the larger DNS systems (90,000+ zones) and our initial testing of the patched BIND showed it having half the performance of prior versions. That prompted us to very quickly replace all BIND caching servers with something else. We had already replaced authoritative services with something else because of BIND's lackluster performance. 3+ hours to load zones on reboot is quite frankly ridiculous. We really had no choice. Microsoft said they were going to open their mouths on a certain date, and we had a massive time crunch. We can't be the only company that simply had to ditch BIND. And I can't say I'm sorry to see it go. I'm sure mister Vixie is a great guy, but his domain name service is, and always has been complete garbage.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
Attention all DJB software fans, here's another chance to champion the superiority of DJB's software.
Yup, and we even have the time, as we are not busy patching our servers!
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
No, its binary, real men solder a telegraph device to the motherboard, and just push down for 1, up for 0, Really, really fast!
What are we going to do tonight Brain?
Don't forget to include positive commentary on the licensing and patch status.
Anyone who champions DJB software already has to bear the burden of running qmail. It doesn't get much worse than that already.
In the free world the media isn't government run; the government is media run.
No. This last week, as often happens, I blindly wandered through the hours in a haze of narcotics and alcohol, vomiting onto my co-workers and randomly saying "whuth day is ih..??". This culminated in me forgetting that it is the second Tuesday in July and therefore due to a long and boring story, the one time in the year where I am meant to come home and cook dinner for the start of a romantic evening with my beloved wife. I think it was rather the straw that broke the camel's back, and she's just this minute left me for a tall Puerto Rican calendar designer. He always knows what day it is.
Oooooh wait, you mean like patch tuesday? Gotcha..
which is totally what she said
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 exploit is trivial to figure out - if a caching DNS server has recursion enabled, and also sends the outgoing DNS queries to the authoritative servers over a fixed (or predictable) UDP port, you can just send forged UDP responses together with your recursive DNS query.
The bogus response will be cached and will affect other users of the DNS server.
The attacker also needs to also guess the transaction ID (16-bit value), but they can send multiple bogus UDP responses with different transaction IDs.
Also, vulnerable implementations may generate transaction IDs in a predictable way, so the attacker can obtain the current state of the PRNG by generating a recursive DNS query to DNS zone under attacker's control.
Such an attack cannot be performed from a typical home broadband connection, as most ISPs will not route packets originating from IP addresses not allocated by the ISP.
The attacker needs to be in control over the routing/egress filtering within his AS (e.g. an enterprise-level Internet service).
throw new SuccessException("Sig read successfully");
[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.
If you don't understand that, you don't need to care.
What's funny is that the CERT advisory gives Dan Bernstein credit for the work around, which he came up with over 7 years ago.