

Massive Internet security flaw uncovered - noodle
http://www.chicagotribune.com/business/technology/la-fi-techblog9-2008jul09,0,1218924.story

======
tptacek
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".

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

~~~
LogicHoleFlaw
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?

~~~
froo
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

------
silentbicycle
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...](http://www.schneier.com/blog/archives/2008/04/reverseengineer.html)

~~~
tptacek
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.

~~~
silentbicycle
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.

~~~
tptacek
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.

~~~
gojomo
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.

~~~
tptacek
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.

------
tptacek
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.

------
antiform
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.

------
gojomo
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/>

~~~
tptacek
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.

