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."
Re:So give a layman explanation (Score:4, Insightful)
If you don't understand that, you don't need to care.
More independent verification needed (Score:3, Insightful)
Here everyone, install this patch to your Unix/Linux DNS servers that was conceived of on the Microsoft campus.
While if true, one should be expedient to fix it, one should also be careful to verify that this is true.
A matter of time (Score:2, Insightful)
This is utterly serious! And only a matter of time before attackers compromise DNS on servers and/or clients.
The good news is this is a really strange situation where the fix does not immediate reveal the vulnerability and reverse engineering isn't directly possible.
And wow! Great news! There's a very critical flaw over the entire Internet name-to-IP infrastructure. But don't bother, it will take time before the bad guys find what we fixed...
Re:More independent verification needed (Score:4, Insightful)
Well of course it is. Anyone can make a list. From the investigating I'm doing right now, it does seem to be legit. But I just think its important to be careful. Don't just blindly patch what is probably the most critical service on your network.
Re:Hmmm (Score:5, Insightful)
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.
Re:not that big of a problem (Score:1, Insightful)
"javascript attack that can compromise a home router"
From one of the articles:
"The technique, called a DNS rebinding attack, would work on virtually any device, including printers, that uses a default password..."
In other words, if you're stupid enough not to change your password, you're going to get your router hacked. No fucking shit, Sherlock.
Great news for Debian users! (Score:1, Insightful)
http://www.linuxcompatible.org/story115154.html
Oh joy!
Re:More independent verification needed (Score:3, Insightful)
Why the sarcasm? If you're hiring sysadmins who aren't also system-level developers, you're not hiring people who can Do The Job Right.
Granted, it's not realistic to read through every patch from upstream... but if it's something you consider that critical and are that suspicious of, yes, your staff should have the relevant expertise in-house to read and evaluate what's going on.
Wait, HOW serious is this? (Score:3, Insightful)
This is from the advisory.
Filter traffic at network perimeters
Because the ability to spoof IP addresses is necessary to conduct
these attacks, administrators should take care to filter spoofedaddresses at the network perimeter. IETF Request for Comments(RFC)
documents RFC 2827, RFC 3704, and RFC 3013 describe best currentpractices (BCPs) for implementing this defense. It is important to
understand your network's configuration and service requirements
before deciding what changes are appropriate.
So...is this REALLY that serious? Is anyone NOT already doing this? I'm incredibly skeptical of big, sensational security alerts like this.
Re:not that big of a problem (Score:3, Insightful)
Re:More independent verification needed (Score:3, Insightful)
but if it's something you consider that critical and are that suspicious of, yes, your staff should have the relevant expertise in-house to read and evaluate what's going on.
Or have the ability to recognise they are out of their depth and be able to use resources from other departments (or even external suppliers)
Re:More independent verification needed (Score:3, Insightful)
Re:More independent verification needed (Score:5, Insightful)
Re:More independent verification needed (Score:5, Insightful)
Re:My first response is to call Bullshit (Score:4, Insightful)
Google Dan Kaminsky and come back and talk.
Re:More independent verification needed (Score:5, Insightful)
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 :)
Re:Oh cool! (Score:5, Insightful)
Article should be modded +1 Ironic because the links necessitate the use of DNS...at the very least, the DNS checker should have been a straight IP.
WTF?
Re:More independent verification needed (Score:2, Insightful)
Hey -- building or patching executables opcode-by-opcode is a time-honored tradition among crackers, old-school virus writers and masochists.
Granted, hex isn't *quite* binary...
Re:More independent verification needed (Score:2, Insightful)
Oh, hush. I'm not (and have never claimed to be) all that good -- the preexisting guru here is way the hell better than I am, and the only thing I need to do to be put in my place is to ask one of my old friends from the embedded-system days what they're working on presently -- many of them are hardcore kernel folks now (a few both were and are Linux architecture maintainers; those folks grok modern CPUs in a way I probably never will). I didn't count those people in the "about five" count because they're too busy to do system administration, and I don't have certain knowledge that they ever picked it up (they were on the kernel development side of the house even back in the day, while I was userland but occasionally moonlighted in their world).
I'm not arguing that putting folks with that kind of skillset to use doing system administration is in any way productive -- but having sysadmins who can grok, debug and extend other peoples' C and do light kernel work when necessary vastly increases the flexibility of your IT department and allows independence in cases where one might otherwise be at a vendor's mercy.
Re:The real solution... (Score:4, Insightful)
The largest DLV repository that validates that the DNSKEYs belong to who they say they belong to (think Verisign-style verification), is run by isc.org.
(My employer, BTW.)
I'm a part of a DNSSEC monitoring project (called SecSpider [ucla.edu]). [...] This serves the same purpose as ISC's repo, but the data is collected in an orthogonal manner. We currently have DLV records for over 12000 zones, although we haven't directly verified the identity of any of them.
That's an intriguing idea, but it doesn't really serve the same purpose as ISC's DLV until you do verify identity. (Would UCLA's lawyers be comfortable with someone relying on your DLV record repository for, say, banking transactions?)
Re:My first response is to call Bullshit (Score:3, Insightful)
It is known for years that it's less secure, if you don't use proper randomization. Now it turns out, it's _really_ insecure. Duh.
Re:So give a layman explanation (Score:5, Insightful)
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.
Pretty sad, actually (Score:3, Insightful)
1. DNS (well, UDP protocols in general) problems have been known for ages. This is nothing new, it's just new because so much drama has been created. There is a reason why certain counter-measures have already been implemented in DNS software. Never mind that noone is using them because it requires effort.
2. So much focus has been put on "phishing". I'd like someone to explain me how phishers are going to forge certificates and get sensitive info? Sure, I'll get bogus IP for the website I want to visit, but unless phishers manage to create valid certificate for gmail.com (for example), I'll get a nice warning box. Which is the same shit as what is happening now, when you go to a phishing website. Those who click "Ok" on every prompt will still get fucked, those who check errors will still not be tricked. Nothing changes.
3. Security became a joke when advisories like "Man in the middle attack allows attackers to steal Myspace passwords" started showing up on first pages of various news outlets.
Re:So give a layman explanation (Score:3, Insightful)
These are my systems, and you're going to tell me precisely what's going on before any of your code gets to run.
So don't trust it. You're already running their code and you seemed quite happy to do so without them telling you precisely what potential bugs could exist. Why get so demanding now?
It's not so much the software. (Score:3, Insightful)
I understand that djb draws a lot of flack for being a legendarily caustic personality; I'm just a little bitter that the sensible parts of his advice get ignored as well. DNSSEC is an implausible mess with a single point of failure, IPv6 migration is a joke, and DNS without source port randomization is vulnerable to spoofing. Despite his other, wackier beliefs (a new format for FTP listings! a new format for mail transfer! blasting mail across parallel connections instead of one connection per server just because I like it that way!), there's some important stuff in there.