Massive Internet security flaw uncovered | Hacker News Reader

Massive Internet security flaw uncovered

chicagotribune.com

11 pointsnoodle21 comments

This is a great example of how bad the press is at handling publicity attacks.

Any open source J2EE stack has at least a 128 bit session ID. Any .NET's is longer. PHP, Python, and Rails all have crypto-unguessable session IDs.

DNS has a 16 bit session ID.

Reliable exploits for this trivial problem have been available since the early '90s. So it's hard to see how we could have a massive new vulnerability in a protocol so fundamentally insecure.

Not only that, but the patch for this vulnerability simply randomizes source ports. DJBDNS has randomized source ports from the day it was released. Randomizing source ports adds ~14 more bits of randomness, when constraints are factored in. A 32 bit session ID still totally sucks, but it's more annoying to attack. But my point is: no vulnerability that is solved by randomizing source ports can be game-changing at this point. I could comment more about the novelty or importance of the attack, but it's inside baseball.

Even more importantly: secure web apps don't rely on the DNS for security. SSL/TLS was designed to assume that the DNS is insecure. It creates a parallel hierarchy that is secured by anchor keys distributed with Firefox, IE, and Safari.

If you are affected by this announcement in any way, "ur doin it rong".

Kaminsky and Ptacek comment on DNS Forgery flaw http://blogs.zdnet.com/security/?p=1466

I am interested in hearing about this new "ninja out of the LCD screen" attack vector.

Are there any current safeguards against the ninja menace?

You know I didn't make that up, right? There was a Ninja Virus in the early 90's.

To my understanding, the only thing that can safely protect you is to wear a Pirate hat and Eye patch at all times.

Consuming copious amounts of Rum may or may not work, as the only people that recommend this strategy are generally drunk - so this information is unreliable at best.

Hopefully on September 19th* we can co-ordinate a proper defense to take out this imminent threat

*September 19th is International Talk Like a Pirate Day

Reliable exploits for this trivial problem have been available since the early '90s. So it's hard to see how we could have a massive new vulnerability in a protocol so fundamentally insecure.

My guess is that the 'new' realization is that the attacks are (for example) 2^16 times easier to perform, or much easier to hide from usual countermeasures. It'll be interesting to see if the hype is justified as the details come out.

What's 'new' are the implications of the attacks everybody already knows about. Nobody really thought it through all the way to the end 10 years ago when DNS cache corruption was discovered and mainly only ever used for creating vanity host names on efnet.

I resemble that remark.

For what it's worth: I retract much of this.

Summary: "There's a highly exploitable design flaw in the domain name system. We're not telling anyone what it is for thirty days, though, so the open-source community can't fix it themselves within days and embarrass larger vendors. Patches will be sent out without context, so as to make it only slightly challenging to reverse-engineer them[1], and impossible to trust they're not actually creating worse vulnerabilities."

[1]: See: http://www.schneier.com/blog/archives/2008/04/reverseenginee...

Well, the original article did include Red Hat in the list of vendors. I don't expect that the details will remain secret for long.

While Red Hat is a Linux vendor, they already have some closed binaries floating around. Look at "binary blob" drivers. http://en.wikipedia.org/wiki/Binary_blob

The research Schneier is pointing to suggests that it's possible to automatically generate exploits from patches.

It's an "open question", but given how much flexibility there is in patching vulnerabilities (effective patches don't need to be tightly correlated with the single broken code path used by an exploit), you can predict what the result is going to be on it.

I linked to it because I think trying to keep it under wraps but issuing binary patches is doomed from the start. I guess my sarcasm wasn't clear enough, so I changed it it "... only slightly challenging ...".

Mainly, I think the computer industry at large should know better by now. Delay the people who would fix things from getting the details they need and hoping the 'evil types' (their words) won't be able to figure it out in the mean time is a pretty bad strategy. (Fortunately, the "good guys" are often good at reverse-engineering things too.)

I don't know anything at all about the technical details here, but it sounds like the whole thing is being handled very badly.

I agree with you. In this case, for reasons I won't go into right here, I think the effort to "hide" this "new flaw" was doomed from the start. But in general, if you patch it, it's out there.

If this announcement counts as "Hackers News", it's marginal at best. "Protocols designed in the '70s found insecure --- film at 11!" But the discussion about whether you can reliable reverse patches to vulns? THAT's fun.

That so many vendors have collaborated to synchronize a patch release is interesting Hacker News. The odd quasi-disclosure -- here's how to test, here's a mostly-helpful patch, but full details will wait a month or until third parties figure it out -- is Hacker News.

Regular reminders of the general insecurity of DNS are also a public service, attached to megapatch firedrills or not.

It would be news if it was (a) news or (b) really true.

Regarding (a), there was more collaboration and a bigger fire drill on the OULU.FI SNMP findings from 2003. That was a series of memory corruption and code execution findings in multiple different implementations.

----------------------------------------------------------

EVERYTHING BELOW THIS LINE WAS WRONG

Also, Microsoft patches on a schedule ("Patch Tuesday"), so if you have an activist security researcher trying to keep details from getting out, the major coordination problem is already solved: you're releasing on Patch Tuesday. What I'm saying is, if you find ANYTHING, and you want to talk about a mass vendor reaction, get Microsoft on board and you're done. Dan has a professional relationship with Microsoft.

Regarding (b), most of the implementations that are patching fall into two categories:

(1) --- Derivatives of ISC BIND

(2) --- Fantastically weak embedded or proprietary DNS implementations that were totally screwed prior to any new research result, and are now catching up on 13-15 years of DNS best practices for fear of being found out.

Hey, everyone: I made a comment above, calling this a publicity attack. Disregard it. Dan has the goods on this one. Patch now, questions later.

So I log into my Debian box, and there are some updates pending with the following description:

SECURITY UPDATE: Randomize UDP query source ports to improve forgery resilience. References: [http://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-1447]

So there's some more information, although it's not saying anything that hasn't already been said. Looks like I'll be patching boxen for the next couple hours.

You can check if the nameservers used by your current machine are still vulnerable/unpatched via a utility at Dan Kaminsky's site:

http://doxpara.com/

Or, let me help you out with this: yes. Even if you're running DJBDNS, your stub resolver (the one linked into your browser and other programs) is weak.

If this was a big deal, you'd have been owned a million times over by now, because this is something that the BIND team declined to fix in 1996.

Reply on news.ycombinator.com