Dan Kaminsky's Blog

I do need to make a post about DNSSEC at some point in the near future.  But for now, I’d like to deal with the more immediate issue:  Moxie’s SSL break.

You’ll note that’s not in quotes.  There’s a pretty decent temptation to say Moxie’s attacks don’t “count”.  Some of this comes from the fact that at the end of the day, these are his three attacks:

First, that when a site attempts to upgrade from HTTP to HTTPS, he can suppress the upgrade — possibly throwing in a “Lock” favicon which might trick the user. Second, that there are a surprising number of online banks that still place a HTTPS form on an HTTP page, which can of course be downgraded (or as I pointed out, sniffed via injected Javascript). Finally, Firefox‘s (not IE’s) defenses against Eric Johannsen’s IDN vulnerability could be bypassed by registering a domain and acquiring a wildcard cert in.cn.

The first two attacks have been discussed fairly extensively, while the third works in only one of the browsers.  So there’s some grumbling.  Lets talk about that.

When I gave my DNS Cache Poisoning talk last year, I devoted quite a few slides to the failings of SSL.  To put it simply, there’s a reason I didn’t consider SSL a sufficient defense for DNS Cache Poisoning. Indeed, the fact that the 302 Redirect could be replaced with a 200 OK — replacing https://www.paypal.com with http://www.paypal.com — is right there on the first slide.  (His favicon trick is neat though.)  And a few slides later, I ended up quoting my 2006 talk with respect to online banks and their tragic use of weak security forms, replete with cutesy “lock” icons.  Obviously I didn’t discover either of these attacks; they, and the rest of the litany of weaknesses described in my 2008 deck, have long been the sort of failings in SSL that we’ve all known are pretty deeply problematic.

But, at least the way I look at it, Moxie’s talk wasn’t about some “l33t new protocol flaw” in SSL.  He’s traveled that ground — in 2002, his finding that a certificate for http://www.badguy.com could sign another certificate for http://www.bank.com via the non-enforcement of Basic Constraints is about as “l33t” as it gets.  That’s been fixed for years though.  This was instead a fairly searing critique about Security UI.  Moxie introduced (to me anyway) the concept of Positive vs. Negative Feedback.  Negative Feedback systems occur when the browser detects an out-and-out failure in the cryptography, and posits an error to the user.  In response to the New Zealand bank data, in which 199 of 200 users ignored a negative prompt, browsers have been getting crazier and crazier about forcing users to jump through hoops in order to bypass a certificate error.  The new negative errors are at the point where it is in fact easier to “balk” — to stop a web transaction, and move onto something else.

I really need to learn to leave DNS alone 🙂

DNS TXT Record Parsing Bug in LibSPF2 A relatively common bug parsing TXT records delivered over DNS, dating at least back to 2002 in Sendmail 8.2.0 and almost certainly much earlier, has been found in LibSPF2, a library frequently used to retrieve SPF (Sender Policy Framework) records and apply policy according to those records.  This implementation flaw allows for relatively flexible memory corruption, and should thus be treated as a path to anonymous remote code execution.  Of particular note is that the remote code execution would occur on servers specifically designed to receive E-Mail from the Internet, and that these systems may in fact be high volume mail exchangers.  This creates privacy implications.  It is also the case that a corrupted email server is a useful “jumping off” point for attackers to corrupt desktop machines, since attachments can be corrupted with malware while the containing message stays intact.  So there are internal security implications as well, above and beyond corruption of the mail server on the DMZ.

Apparently LibSPF2 is actually used to secure quite a bit of mail traffic — there’s a lot of SPAM out there.  Fix is out, see http://www.libspf2.org/index.html or your friendly neighborhood distro.  Thanks to Shevek, CERT (VU#183657), Ken Simpson of MailChannels, Andre Engel, Scott Kitterman, and Hannah Schroeter for their help with this.

Edit:  Special thanks, incidentally, to Coverity, who upon hearing that there was one bug, ran their static analyzer on LibSPF2 and found six more.  Cool!

Someone asked for a cite on the Consumer Reports claims in my Black Hat 2008 slides.  I went and tracked this down, and I actually picked this up from the Meandering Wildly blog.  Looks like I misread this a bit — a previous dataset had come from Consumer Reports, but the data in my Black Hat deck actually came from Venafi, a security firm that specializes in systems management.  Some collateral with more of their SSL data is here.  Their methodology for collecting the data, according to Meandering Wildly:

It’s a phone poll, so it’s subject to standard errors of self-reporting, and their margin of error (2.5%) is given for a 0.1 confidence interval, which is a little slack for my tastes, but they have a large (N>1000), US-Census-representative sample, which maybe gives us intellectual permission enough to keep playing.

Of course, I also spoke about the one case we have hard data on — when the New Zealand bank’s cert went bad, and 99% of people didn’t care.  Information on that case can be found here.  I do wonder how these numbers might be changing in light of IE8 and FF3’s dramatically improved invalid SSL certificate experiences.

In general, anything I claim, I’m only too happy to back up, so if you have any questions regarding any of the details from a talk I’ve given, don’t hesitate to ask.

So, after I completely whiffed on the initial disclosure of the DNS flaw, I wrote the following:

So there’s been some skepticism about the DNS flaw. I want to be clear: It was richly deserved. A “put up or shut up” mentality is critical to the survival of our industry. It’s just too easy to make stuff up, if you can just wave away detractors with “I can’t prove it…it’d be UNSAFE.”

The danger from that statement is very tempting and very real. Our credibility as an industry — ultimately, our ability to get bugs fixed — depends on that statement being called out as the bullsh*t that it is.

We, as an industry, have gone back and forth on full disclosure (i.e. tell everyone) vs. responsible disclosure (i.e. tell everyone after the vendor has had a chance to fix things). Partial disclosure has always been looked down upon, rightfully so, because it’s so amazingly easy to abuse. But if our goal is to protect customers, and one particular bug will affect almost all of them, and a phased disclosure of information will protect the greatest number of customers possible — then perhaps there’s a place for this mode.

It’s certainly not a path you can safely decide to take by yourself, however. That’s what I did, when I refused to tell anyone else in the security industry what the bug was. It’s not something I’d ever do again. It’s not just that you can’t vouch for your own bugs. It’s that, without peer review, you don’t know what bugs people are going to think you’re recapitulating, and you even don’t really understand the severity of your issue.

It’s your blood, sweat, and tears in there. Hard to be impartial.

So Sarah Palin’s webmail was hacked recently, ostensibly through a “forgot my password” attack. Venturebeat‘s Dean Takahashi remembered that I’d recently been warning about these systems at Black Hat, and solicited my opinion. Here’s what I had to say.

My observation then was that the unifying theme of the bugs of 2008 has been a complete failure to authenticate.

I have to admit, I’m a little surprised to see the theme infecting the election. But, there it is. Webmail providers have a particularly tricky problem with “Forgot My Password” links: They can’t presume you have some mail address to send a password or a reset link to, because they *are* your mail address. With nothing else they can go on, they end up trying personal entropy — secrets like when you were born, where you went to school, etc.

In an increasingly less private society, “secrets” like your birthday are easier and easier to acquire from just normal people — let alone massively visible Vice Presedential nominees like Sarah Palin. So personal entropy is now struggling even more as a mechanism to authenticate.

People have suggested — why not use the telephone system? Everyone has SMS (text messaging). From one perspective, this is completely true. From another, in this increasingly less private society, a decent number of people are specifically averse to having to permanently identify themselves to websites. (Skip a few chapters, and you can watch SMS spam explode as every website collects those numbers ‘in case you forget your password’.) And so we end up at OpenID and its ilk, which attempt to solve the problem of password forgetting by having all sites (effectively) share the same password, or at least authentication technology (since you might use a key fob to log into your OpenID provider). This has some downsides, but isn’t necessarily bad.

One quirky thing, given the election, is how electronic voting and the latest Forgot My Password hack play into one another. People want to vote, but they want their vote to be secret, but they want to be able to detect fraud, which normally requires validating the voter to their vote. People also want to log into their websites, but they want their real identity to be obscured, but they want to still be able to get in if they forget their password, which normally requires validating the real identity to the account. We can say this is ridiculous all day, but there are many people who won’t vote if their ballot isn’t perceived as secret, and there are many people who won’t use the web if their personal identity isn’t perceived as secret.

In security, we have something we call the Birthday Paradox, which is well illustrated by the following question: How many people do you need in a room, before it’s more likely than not that there are two people with the same birthday? Most people think the number’s pretty big — 50, 60, 100…nope. It’s around 27. Most classrooms have two kids with the same birthday. This happens because the more kids you add, the more birthday “slots” are taken that each new kid might potentially now share. The 2nd kid had only 1 birthday to match, while the 25th kid had 24 birthdays he could match.

Well, I have my own paradox. I call it the Renderman Paradox. This holds that, for any conference, there’s someone you’ll never get to see, because somehow you’re always speaking at the same time they are. I call it that, because, well, Renderman (of the Church of WiFi) and I are always up against one another. Finally, this year at Defcon, we weren’t. Renderman was in my room, yes, but after me. And then…

Well, there were a couple thousand people in line. It took a while to get ’em all in. Actually, it took about a half hour to get them all in. So, the Defcon people bumped Renderman, and Sze Siong, to an overflow room.

I gave my talk to the hordes…but these guys had space for about 50. Ouch. Bonus: Renderman’s talk was “10 things that are pissing me off”. Oops 🙂

And so, I thought it might be nice to at least publish Renderman and Sze’s talks here. First up, Renderman (here’s his site, with video!):

Renderman’s Slides

So someone put together a “one character” patch to fix the “dns flaw”, and it hit Slashdot.

Would that one character could really save the day here.

There’s a lot wrong here, the key fact being there are just so many ways around TTL, which itself was never designed to be a security technology in the first place. Gabriel’s trick addresses one particular scenario. It’s not at all enough. Consider:

First of all, you don’t actually know that a nameserver is ever going to provide you a record, or that that record is going to be cached. We’re seeing bugs in both conditions. For example, PowerDNS wasn’t providing responses on strange query types. CNN doesn’t reply at all to nonexistent names. So there may not be a TTL to bypass.

Secondly, the more major the site, the smaller the TTL. One of the issues described in my slides was the fact that nothing prevents an attacker from replying multiple times to a single outbound query. Presume you can get 500 replies in before the real server does. Given that, you have about a 1 in 131 chance of hijacking the record. With Google Analytics’ TTL at 300, that’s about 5 hours on average — and you don’t have to send 4 billion packets, you’re still sending just a couple tens of thousands.

If Google Analytics gets taken, the web pretty much gets taken — welcome to the power of <script src=”http://www.google-analytics.com”&gt; putting foreign code into DOM’s around the world.

Ultimately, I can’t at all complain about armchair engineering.  The whole point of Source Port Randomization as an interim fix was to get things to the level that we could all have the big messy discussion about what to do now, without being illuminated by the actively burning state of the DNS infrastructure.

Now.  When it comes to fixing DNS, we have to operate under the same constraint as when we suggest fixes to web browsers.  Just as you’re not allowed to break the web, you’re not allowed to break DNS.  There are indeed many things we could do to make the web a safer place, “if only a bunch of people would re-code their web sites”.  That is, unfortunately, a naive approach that doesn’t actually lead to things getting any safer.  If nobody will deploy the fix, it’s just as if the fix didn’t happen.

We needed this DNS fix to happen.

As I’ve said a couple of times, Dan Bernstein was right.  Source Port Randomization (SPR) is not perfect — I’m pretty embarrassed that we didn’t recognize how common interactions would be with firewalls — but it’s a remarkably flexible and thorough improvement to the status quo.  When I said in my talk that there’s fifteen ways around the TTL, I wasn’t kidding.  From magic query types that are uncached by a recursive server, to nonexistent query types that are ignored by an authoritative server, there may not be a TTL to override.  Or perhaps the attacker actually provides records for 1.google.com, 2.google.com, 3.google.com, and so on.  In other words, the attacker might not even try to overwrite the NS for a domain — he may just want to get a domain in.  How would this be useful?  Consider the web security model, and Mike Perry’s research on cookies.  1.google.com will collect the cookie for Google just fine.

Or perhaps, as in the case of Google Analytics and Facebook and most large, CDN hosted sites, the actual TTL to override needs to be small, for reliability and scaling purposes.

In all of these situations, Source Port Randomization — a solution forged in 1999, long before we recognized all these problematic variant attacks — poses a significant barrier to attack.  It’s not a panacea, but it was never said to be one.  The hope, and it’s not unreasonable, is that it’s a lot easier for secondary defenses to detect and correct for a flood of billions of packets, than a couple of thousand.  SPR’s purpose was to provide a safer environment for an active discussion that would hopefully yield better fixes.  And that’s what it’s doing!

I’m not sure what it is, but there continues to be some sort of “competition” for “who can find the biggest bug” — as if attackers had to choose, and more importantly, as if any bug was so big that it could not be made even better by combined use with its “competition”.  Before my DNS talk, my old friend FX from Recurity Labs was comparing DNS issues to the Debian Non-Random Number Generator issue that caused all sorts of SSL certificates to offer no security value, and the SNMPv3 flaws that allowed infrastructure devices to be remotely administered by people who happened not to know the password.

Of course, after the talk, it became clear that the DNS hack and the Debian NRNG combined rather destructively — DNS allowed you to finally play MITM with all the SSL private keys you could trivially compute, and as Ben Laurie found, this included the keys for Sun’s OpenID authentication provider.  And, since the DNS hack turns Java back into a universal UDP and TCP gateway, we end up being able to log into SNMPv3 devices that would otherwise be protected behind firewalls.

So there’s no sense making a competition out of it.  There’s just an ever growing toolchest, growing from a single emerging theme:

Weaknesses in authentication and encryption, some which have been known to at least some degree for quite some time and many of which are sourced in the core design of the system, continue to pose a threat to the Internet infrastructure at large, both by corrupting routing, and making those corrupted routes problematic.

Back in July, the genuinely brilliant Halvar Flake posted the following regarding the entire DNS issue:

“I fail to understand the seriousness with which this bug is handled though. Anybody who uses the Internet has to assume that his gateway is owned.”

🙂