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."
Oh cool! (Score:5, Funny)
Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.
Sweet!
Re:Oh cool! (Score:5, Funny)
In fact, we arent even www.doxpara.com, we just hacked your name server. That's how we know.
Re: (Score:2, Offtopic)
Not only that, its been slashdotted.
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: (Score:2)
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.
Re: (Score:2, Informative)
Re: (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 shou
Re: (Score:2)
Are you seriously suggesting the possibility that this is a plot by Microsoft to somehow break or degrade Unix/Linux servers?
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: (Score:3, Funny)
If you're using a Linux DNS server that's open source, why don't you just read through the source code and find out what changed, I mean, psht, it's so easy?
Yes, I'm being sarcastic.
Re: (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 expe
Re: (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: (Score:3, Insightful)
Re:More independent verification needed (Score:5, Funny)
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!
Re:More independent verification needed (Score:5, Funny)
Re:More independent verification needed (Score:5, Insightful)
Re: (Score:3, Informative)
Job titles in our industry have always been a bit hazy, though. Perhaps the confusion arises because of
Re: (Score:3, Informative)
Those tend to be referred to as network and system engineers these days.
Re:More independent verification needed (Score:4, Funny)
Re: (Score:3, Interesting)
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: (Score:3, Funny)
We are all duly impressed with your superhuman abilities. We recognize that you are a superior form of human being, and should really be placed in your rightful place as Emporer of Earth. We are but children compared to the greatness that is you.
Re: (Score:3, Interesting)
I should have specified senior sysadmins, to be sure -- there's no reason to be that picky about everyone on staff. OTOH, the whole point of having senior people is to have someone who can dig into and eventually solve any issue that comes up -- and that means understanding what's under the abstractions. Addressing your comparison, software isn't as reliable as hardware is these days; maybe in ten years this won't be the case, but right now having someone available who can dig into the operating system (or
Re:More independent verification needed (Score:4, Funny)
It's easy, you just look for a comment like: /* BEGIN bug causing possible MASSIVE future EXPLOIT. */
Re: (Score:3, Funny)
Re:More independent verification needed (Score:4, Funny)
Re:More independent verification needed (Score:4, Funny)
Oh, the only one your *really* need to look for is // should never happen
although // drunk now, fix later
is also good.
Re:More independent verification needed (Score:4, Funny)
/* John was hit by a bus last week :( I have no idea what he was doing here, I'll just return 1 and hope for the best.. */
Re:More independent verification needed (Score:5, Insightful)
Re:More independent verification needed (Score:5, Funny)
> Microsoft's own DNS implementation is also affected
Did anyone else notice that today is Tuesday?
Re:More independent verification needed (Score:5, Funny)
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..
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.
Re:not that big of a problem (Score:5, Interesting)
And that's precisely why the first thing I do on a home router is to disable the cashing nameserver and install DJBDNS on a Linux box instead. :)
Re: (Score:2)
Would you be kind enough to publish your iptables config that does that? Such a set of rules seems like it would be very useful.
Re:not that big of a problem (Score:5, Interesting)
[This is Dan Kaminsky]
No, this attack is much worse than my home router exploits (which, admittedly, aren't getting fixed anytime soon). While it is indeed nice to have compromised firmware living somewhere on your LAN, being able to generically attack everyone using a given ISP is a much more valuable proposition -- especially when I don't need to worry about the pesky paranoid people changing their router passwords, or even using a router I haven't built a script to attack.
I'm being very circumspect about implications. August 6th will be an interesting day.
It's funny you mention the iptables auto-block. There's been a known attack here for years -- spoof the root servers attacking you, and...yeah.
That being said, we agree on the ultimate fix...run yum update, and be done.
Re: (Score:3, Interesting)
Re: (Score:3, Funny)
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.
Ahhh the joys of default passwords. I remember my high school's implementation of network security which had a few default passwords just waiting be found via lycos... or was it hotbot back then?
Either way when it was discovered I was assuming control of my work station to increase screen resolution to effectively use the IDE they had provided, well they slapped me on the wrist and brought me back down to 640x480 for security reasons of course. When I said fuck it and wrote a program that changed the res
Re: (Score:3, Insightful)
Hmmm (Score:2)
So, uhh, why the secrecy in planning the fixes?
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.
DJBDNS not affected. (Score:5, Informative)
Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.
Let the DJBing begin! (Score:4, Interesting)
Attention all DJB software fans, here's another chance to champion the superiority of DJB's software. Don't forget to include positive commentary on the licensing and patch status.
Thanks!
Re:Let the DJBing begin! (Score:5, Funny)
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...
Re:Let the DJBing begin! (Score:4, Funny)
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!
Re:Let the DJBing begin! (Score:5, Funny)
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.
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: (Score:2)
Now hold on. I read the article, and it didn't say what the vulnerability was. So your assertion that a particular technique would protect against this particular vulnerability must be based on knowledge of what the vulnerability entails, but the article is claiming that this is some big secret. Care to elaborate?
Re:DJBDNS not affected. (Score:5, Funny)
Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.
Also not affected: DJBDNS's IPv6 and IXFR functionality, since Dan didn't want to bother implementing them.
Sinisterness (Score:3, Funny)
FTA Update: Dan just released a "DNS Checker" on his site Doxpara.com to see if you are vulnerable to the issue.
in other news
Sooooooo, Im supposed to run a random file on my network to check an unknown DNS issue...this just reminds me all too much of those "download our program to fix all your antispyware issues" alerts.
And finally the obligatory profit usage:
1. Find a vulerability
2. Dont tell anyone what said vulnerability is.
3. Release malware in the form of a "Patch" to "Fix" the issue exploiting thousands of servers.
4. ???
5. PROFIT!
Re:Sinisterness (Score:5, Funny)
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.
Re: (Score:2)
Release malware in the form of a "Patch" to "Fix" the issue exploiting thousands of servers.
Well, you have to trust your vendor at some point right? Trust enables us to run yum or apt-get without having to read every line of source code for each upgraded package. I suppose having an open-source vendor is an advantage if you don't trust your supplier. But if you don't trust them why are you using them?
The fact that so many are doing this at once might be a clue that it's real.
Re: (Score:2)
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.
I would say that this is a pretty serious issue... (Score:2, Interesting)
Re:I would say that this is a pretty serious issue (Score:2)
Serious only if you're using BIND and a non-SOA DNS server. See http://secure64.com/products.shtml [secure64.com] for good reasons to ditch BIND if you have some spare $$.
Remember: no cache, no fooling around with cache for giggles.
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...
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.
Re: (Score:3, Funny)
When an absolute statement is modified with an adverb, the statement is not generally true. Examples:
Oh noes, mah DNS! (Score:2)
Finally...! (Score:5, Funny)
Needless to say, my first impression of the headline was way more futuristic than what is there.
Re:Finally...! (Score:5, Funny)
Welcome to the fail that is "no unicode on slashdot". Enjoy your stay.
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.
Just in time for DefCon (Score:2)
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
The real solution... (Score:5, Interesting)
...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 [rfc-archive.org] (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.
Re:The real solution... (Score:5, Interesting)
The political will has been shifting a lot lately. I've spoken directly to the gentleman in charge of managing the root zone, and he says that technically speaking it would be an overnight change. All the DNSKEYs and RRSIGs have been generated, he's waiting for the OK from above, which he says appears to be more likely with each passing day.
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. At this writing, this zone has a grand total of twenty five DLV records. Not exactly what I would call useful from a security standpoint, although it is a start.
I'm a part of a DNSSEC monitoring project (called SecSpider [ucla.edu]). We have a set of pollers distributed around the world from which we collect data about the current deployment. In conjunction with this, when we are able to collect an identical DNSKEY RRset, we generate DLV records and serve them from one of our delegations. For details on how to use it, check out our blog [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.
This I can't disagree with. DNSSEC is over-engineered by academic crypto people. In fact, DNS in general is somewhat over-engineered, but at least it was successfully rolled out. ISC's efforts are valiant, and hopefully with a larger roll-out their tools will become de-facto.
Yes, the difference is that impossible isn't possible. You can't stop a determined hacker, not even with the best technology (think of social engineering attacks). Security is like an onion: as soon as you pull away one layer there are a dozen more to get in your way.
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?)
Lots of unkkon statuses... (Score:2)
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.
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]
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.
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
The nature of Reverse Engineering (Score:2)
The Death of BIND (Score:5, Interesting)
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.
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:The Death of BIND (Score:5, Interesting)
We've known about it for a while. Certain providers were contact about it a while ago. Any other information is confidential, as I said, not my call. We were seeing QPS start out at 5,000ish then drop to 3,000ish during our testing. With the 30ish days we had to react, the path of least resistance was replacement. The only version we were given to play with was 9.5.0rc1, which was three weeks ago. Understand that all this was driven by Microsoft saying they were going to spill the beans on a certain date. So your "now" wasn't good enough to meet our deadline. I'm not a huge fan of replacing production services that are "working fine", and BIND was performing adequately for us before we got the word on this vulnerability from one of our vendors. At this point, we are "BINDless" though, and the mountains we had to move will probably not be moving back.
Re:The Death of BIND (Score:5, Interesting)
Thank you for your reply.
The only providers who should have received the patches earlier than today were a small group of our support customers who've contracted for advance notice of security issues. They were all told that this was a preliminary patch only, and to watch for betas with better performance--and that the patches were highly confidential and covered by nondisclosure agreements.
Your installation profile doesn't seem to match any of theirs, and in any case I hope they would have let us know before they eliminated BIND from their networks. If you are not one of our support customers, then I'm very concerned that you had the patch in your hands as early as you say you did. Partly because it means you only got a partial picture of the situation, and partly because it means someone violated our trust--and it's important that we know who, so we can emphasize to them that this is not a joke.
Can you please tell me where it was that you got the patch you tested?
Re:The Death of BIND (Score:5, Interesting)
I am one of your support customers. Thing is, I'm not comfortable saying much else because we were told the 10th was the magic day, and it leaked 2 days early. To be clear, the patched BIND worked the way it's supposed to, and I'm sure it's going to work fine for most customers. With the news that you have patched versions that address the issues with heavily taxed servers, probably almost all of them. We jumped the gun because that's what we do. : ) And I'm sorry I was critical on BIND. It is still the industry standard, and the original daemon that made it possible to get rid of enormous host files. There's a degree of comfort in running *the* DNS daemon, and we were doing it even though my organization is decidedly anti opensource. That speaks volumes.
Re:The Death of BIND (Score:4, Interesting)
Ah. Well, that's a relief, then, of sorts. :)
Thanks for the kind words about BIND and I'm sorry it didn't meet your needs this time. Please encourage your management to contact ISC and tell us about your choices and your experiences.
Re: (Score:3, Interesting)
Oh, and despite the Ron Paulesque nature of the DJB fanbase, I'd still recommend the djbdns suite as the best free solution. I can think of a little ISP in Iowa that I set up with djbdns that has to be happy they don't have to do a thing right now.
ok, who let the Debian guys loose again? (Score:3, Funny)
from http://www.kb.cert.org/vuls/id/800113 [cert.org]: "The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID."
Just put the real seed back into the code.
obrant: and who the frak releases advisories in DOC format in the 21st century?
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:4, Insightful)
If you don't understand that, you don't need to care.
Re: (Score:3, Interesting)
Do I trust it? I don't know. Tell me the facts. The sheer quantity of internet shenanigans going on of late makes me suspicious. This sounds like they're patching for a remote root exploit, but a protocol issue won't do that. DNS poisons? What is it then?
They're making us patch everything, and aren't telling us what it does. These are my systems, and you're going to tell me precisely what's going on before any of your code gets to run.
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:So give a layman explanation (Score:4, Informative)
Re: (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?
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.
Re:So give a layman explanation (Score:4, Funny)
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:Any name server? (Score:4, Funny)
" Everybody else is being patched to the level of security that we djbdns users have always had. Not to be *too* smug, of course."
Bingo.
If we were being smug we'd say something like "what do you expect when cert advisories are published as doc files?".
Re: (Score:3, Funny)
Reportedly, djb wears all black, not all-aluminum. If I were you, I'd start wearing all black also.
Re: (Score:3, Informative)
djbdns consists of a separate server (tinydns) and resolver (dnscache).
Re:My first response is to call Bullshit (Score:4, Insightful)
Google Dan Kaminsky and come back and talk.
Re: (Score:3, Funny)
Its a problem in the protocol. So the only systems that would not be vulnerable are those that did -not- follow the specs. Guess Windows is safe, since Microsoft never follows the specs :)
Re:My first response is to call Bullshit (Score:5, Interesting)
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).
Re: (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: (Score:3, Informative)