What FX has shown is that each hardware line tends to have enough in common that exploits can be built independent of the individual version of software deployed on that piece of hardware. That's a decrease in variability of at least a couple orders of magnitude.

This is Dan.

OK, my DNS bug took two days to find, and six months to fix. I'm not sure what universe you're in; in mine, we have to actually test.

Sup Goth, this *is* Dan.

!exploitable isn't about finding bugs -- it's not a fuzzer, it's not a static analyzer, etc. It's about looking at a crash and saying, "Heh, this isn't just a Null Pointer Deref, you got EIP." Sure, that's obviously exploitable to you, but to some junior tester, that's not obvious at all.

That's why it's a game changer. The dev writing the buggy code can't just say, meh, prove it's exploitable. Now the tester can point out the output of !exploitable and say, prove Microsoft is wrong. Shifts the burden of proof in the exact direction you'd want.

This is true historically. However, I (this is Dan Kaminsky) think it's a mistake now. DNSSEC needs to be pushed into the nameserver's automated functionality about as deeply as possible. Administrators simply cannot be asked to maintain this data, manually resigning zones, manually keeping keys from expiring. It doesn't scale.

Don't worship DJB too closely. Remember the birthday attacks from 2002? DJBDNS only got patched against them a week or two ago...not even after I pointed out that their protection was missing, but after Kevin Day went ahead and built an exploit against it.

Well, for one thing, 1.www.google.com has access to the www.google.com cookie. It's also a really good place to phish from. In some circumstances, document.domain is even set up such that 1.www.google.com has script level access to www.google.com. Not good.

At this point, BIND, Nominum, Unbound, and Microsoft all suppress colliding queries. The only name server I know of that doesn't is DJBDNS, and it drops its security level noticeably.

It's everyone with an EV cert.

Green bar is a great marketing ploy, but it really should be an httpsev:// URL handler if we wanted it to be secure. Collin Jackson's done some really good work around this, go google him.

Technically, everything in Paketto comes from a rather evil reading of TCP RFC's :)

Since the non-green-bar site has Javascript access to the green-bar site, the green bar doesn't actually mean anything.

See http://www.doxpara.com/DMK_Neut_toor.ppt to see why this is still a problem.

Oh come on, ARP cache poisoning is trivial :) There's also a good dozen ways on LAN to hijack all traffic, so you're never fixing that.

Glue distrust isn't that big of a deal. It's sufficiently damaging to the browser security model just to inject arbitrary subdomains into extant domains.

And, no offense to DJB, but port randomization is not by itself a sufficient response to the birthday attack. Come on, we've known not to have simultaneous outstanding requests for the same name for the last six years.

Regarding EV, https://www.yourbank.com (EV cert) == https://www.yourbank.com (domain validated cert) -- as far as the browser's Same Origin Policy is concerned. So the attacker passes through enough EV for the bar to turn green, then switches over to DV for JS to come in. Not good.

The idea was that you'd target individual ISP or Enterprise name servers, which would be trivially reachable via a simple ad network. You'd hit com, then use basic caching to grab what you liked.