Slashdot Mirror
Kaminsky DNS Bug Claimed Fixed By 1-Character Patch
An anonymous reader writes "According to a thread on the bind-users mailing list, there is nothing inherent in the DNS protocol that would cause the massive vulnerability discussed at length here and elsewhere. As it turns out, it appears to be a simple off-by-one error in BIND, which favors new NS records over cached ones (even if the cached TTL is not yet expired). The patch changes this in favor of still-valid cached records, removing the attacker's ability to successfully poison the cache outside the small window of opportunity afforded by an expiring TTL, which is the way things used to be before the Kaminsky debacle. Source port randomization is nice, but removing the root cause of the attack's effectiveness is better."
Update: 08/29 20:11 GMT by KD : Dan Kaminsky sent this note: "What Gabriel suggests is interesting and was considered, but a) doesn't work and b) creates fatal reliability issues. I've responded in a post here."
Update: 08/29 20:11 GMT by KD : Dan Kaminsky sent this note: "What Gabriel suggests is interesting and was considered, but a) doesn't work and b) creates fatal reliability issues. I've responded in a post here."
If this is indeed not a protocol flaw, how come the same vulnerability is present on other DNS servers as well ?
Do they all use the same code from BIND for this particular 'feature' ?
@neonux
Ok! Ok! I must have, I must have put a decimal point in the wrong place
or something. Shit. I always do that. I always mess up some mundane
detail.
This is not the first time a huge security vulnerability was fixed by changing a single character!
From what I remember, the SSL vulnerability we saw a while ago was caused by a single excess comment mark (well, maybe two if it was a double forward slash
(and I think for speak for everyone), this is how I feel about it:
!
meep
It does not fix the case where the attacker first tries to poison aaaaaa.example.com, aaaaab.example.com, ... , fc4dss.example.com until he succeeds with the glue-record being the real evil. In that case there is no previous cache-entry to rely on.
is dead. And Slashdot isn't reporting it. I guess that are too busy with the idle section.
That would probably be because Steve Jobs is not dead, though that never stopped them before, given BSD's "untimely demise". ;)
My blog
Updating a cache with new data when the source data changes before the cached copy is a bug?
The "root cause" is being able to fake being the correct source of the data being overwritten, NOT the ability to refresh a cached copy.
And AFAICT, the ability to falsify data sources remains a FUNDAMENTAL flaw in DNS.
That would be because Steve Jobs is not dead.
My blog
....Paul Vixie is no longer allowed to commit code to BIND. Can this vulnerability be traced to code that he DID write originally?
From one of the mails of the guy who made this proposal:
What's the downside to my patch ? I guess we are now holding an :)
authoritative server to the promise not to change the NS record for
the duration of the TTL, which is kinda what the TTL is for in the
first place
I wonder if this is an issue. Otherwise it seems Kaminsky may really have missed the point.
It's 570MB.
I'm so bored that I actually read the post in the mailing list and all the replies in the thread.
Just to be at the same time informative and to the point, the 7 replies so far have been as positive as this patch is in the linux kernel mailing list a few years ago.
I'm not an expert so please ignore (or better .. explain) this if I'm way off but Google adives TTL 1 week when using their GoogleApps mail server. So .. what if I really really want to change my MX after 2 days? :-/
mov ax,4c00h
int 21h
(Source unknown)
A manufacturer had a problem with one of the older machines on their line. It shut down the line and held up production, costing many thousands of dollars in lost production. Since it was older equipment it was hard to find someone knowledgeable in repairing the machine, and nobody on-site knew what the problem could be. They found a technician with knowledge of the machine and hired him to come in and fix it.
When the technician arrived on site he listened to the client's description of the problem, examined the machine, opened a panel, and turned a single screw. He restarted the machine and it was back to full function. The line was up and running and the manufacturer was happy.
A week later the manufacturer received a bill for services: $1000. They called the technician and demanded an explanation - after all, they reasoned, he had only turned one screw to fix the problem. He agreed to re-bill, this time with itemized charges. The next bill contained two lines.
Turning the screw... $1
Knowing which screw to turn... $999
Why, oh why, didn't I take the Blue Pill?
This has more to do with an oversight in the DNS standard - doesn't have anything to do with any single implementation. Windows, Linux, and any other networked system that uses DNS are equally affected.
Besides, it doesn't matter if your operating system is Open Source. You can write closed or open source software on any platform you want, and just because the source is available does not necessarily mean that bugs will be noticed and fixed. This situation just shows that even if there are no 'bugs' in an implementation of a standard, the original design may still be flawed.
I haven't been following this situation very closely, so perhaps I'm a bit off with the details, but I'd be happy for someone to put me right if that's the case.
Favouring cached DNS records seems to me to not be a spectacular idea for all situations. It depends on the length of the TTL setting on your DNS server though. I'm not sure what expiry time would be sensible for an ISP to use. You have to balance the fact that you want to up to date records with the amount of overhead that will be generated by all the DNS traffic.
which is totally what she said
Is this going to break dynamic DNS services like redirectme.net?
"Knowledge is the only instrument of production that is not subject to diminishing returns" -Journal of Political Econom
Steve Jobs is alive and Slashdot isn't even covering it. This place blows.
Well, thanks to the Internet, I'm now bored with sex.
This is NOT a fix to the root problem of the Kaminski vulnerability.
The root problem is the cases where athority/additional/unasked-answers are accepted, and there are plenty of variants this "patch" does not affect. EG.
Answer:
whatever.foo.com CNAME www.foo.com
www.foo.com A 66.6.66.6
Authority:
(usual goop).
If www.foo.com is not yet cached (and often even if it is), this will set it as a Kaminski variant.
Test your net with Netalyzr
Ever since seeng this I don't trust that one character, Patch.
Slashdot Burying Stories About Slashdot Media Owned
Forget that. Shouldn't we have regular updates on whether or not Charles Babbage is still dead? He's the father of computing itself, for fuck's sake!
wait 6 or 7 months and then we'll see 3 or 4 dupes about how he's dead, how he isn't and how tragic it is that he died before he could vaporize psystar with his reality distortion field
Maybe we should have a Charles Babbage status page a bit like this one:
Abe Vigoda
We need a site like this:
http://www.abevigoda.com/ffb.php
for Steve Jobs... you know just to be sure.
I don't give a damn for a man that can only spell a word one way.
Mark Twain
They stopped random UDP port use, and now use a static pool of UDP ports for queries. Note that they have come out with a P2 release that addresses a completely different issue that the first patch caused. I was able to essentially cause a DOS on a BIND server that was patched with P1 by sending more than 10,000 queries to the system. It ran out of usable UDP ports and puked. The same issue exists in the Windows patch, and especially on Windows 2003 SBS. There was way more than one line of code, or a single character changed.
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
Perhaps the people that came up with this as the "real fix" should consider the case when the NS records for a particular domain are not cached. There's not only a single scenario to consider when coming up with a patch, which is why defense in depth is important. This is not a complete fix without source port randomization.
I'm probably missing something, but does this solution not impact an organization's ability to recover from varying DDoS attacks?
If I have to wait for all of my records to expire before I can shift my website from an IP that is being targeted by an attack, does that not leave me vulnerable for longer?
Some rapidly changing domain names, used for things like Russian Business Network (and reputedly for frauds and so on) might be hard (harder anyway) to do with this patch, since old DNS records will tend to remain in force until their TTL expires. This might be a good thing, and at any rate it would make it easier to notice when a DNS resolution was perhaps suspect. Any DNS resolution that was going to change every few minutes would need a very short TTL which might be possible to ignore programatically.
in Managed and Monitored mode.
YHBT. YHL. HAND.
I didn't have time to read everyone's post here but the one thing I think everyone is forgetting or overlooking is why cache was created/used in the first place. 1st. Could you imagine the amount of extra traffic on the internet and core devices if every lookup had to traverse the net? It was designed because there is no need to change you DNS RRs constantly they should be static, or failing that only needed to be update once in a while. 2nd. what happens if my DNS serves go down (yes assuming both of them go) I can assume that at least some people can still find my service based on cached results from ISPs or root servers. Contrary to what I just said I also agree that the internet backbone is huge and could handle the extra traffic and maybe it is time to rethink old policy. just because its worked in the past dose not mean we have to continue to use it for the future. A lot has change since the first inception of the DNS RFC.
Kaminsky has an interesting rebuttal here.
TY AC. BTW ILU.
which is totally what she said
i know of forms of poison that do not involve the authority section at all.
i know of servers with no BIND code inside that were poisoned by kaminsky.
i know of valid configuration changes that depend on NS RRset replacement.
is this a troll of some kind? as slashdot lead articles go, this one shows unusually high disinformation and ignorance.
A detailed explanation of the Kaminsky exploit can be found here: http://thefrozenfire.com/data/dnspoisoning.html
Without even bothering to RTFA, I'm going to hazard that the patch was a '!' right before a '=' ;)
But what if I really want to change a record, that hasn't expired yet? Will the fix force me to live with the old values until they expire?
In Soviet Washington the swamp drains you.
Steinmetz retired as an engineer from General Electric to teach electrical engineering at that city's Union College in 1902. General Electric later called back as a consultant. He had worked on a very complex system that was broken. No one could fix it no matter how hard the technicians tried. So they got Steinmetz back. He traced the systems and found the malfunctioning part and marked it with a piece of chalk.
Charles Steinmetz submitted a bill for $10,000 dollars. The General Electric managers were taken back and asked for an itemized invoice.
He sent back the following invoice:
Making chalk mark $1
Knowing where to place it $9,999
Actually....
This is Dan Kaminsky, finder of the bug.
No, this isn't a reasonable fix. Nice try, but no. See http://www.doxpara.com/?p=1234 for details.
(Incide
I'd just like to say that during all of this the one man that deserves the community's recognition is DJB. I've been following this on and off since the exploit erupted and through out all of it the one thing that has been missing is significant, heartfelt praise for DJB. He's often maligned by the open source community for releasing his code to the public domain but the fact remains the guy produces and ships kick ass code. Qmail and Tinydns absolutely rock and I think it's a great shame the man doesn't get the recognition he deserves. It's mildly ironic that another of today's Slashdot stories talks about the problem of multiple open source license proliferation with many people stating the solution should be releasing code to the public domain. This is exactly what DJB did and he got torpedoed for it.
DNSSEC was the counter measure that was designed to beat this attack scenario as well as lots of other threats. It still is the only real solution to this problem.
It defeats both on path and off path attacks.
It is a enabler of other security measures.
e.g. SMTP security depends, in part, on getting valid answers out of the DNS. You need to know which certificate names to trust and without a secure DNS you don't have that.