Dan Kaminsky's Blog

So some people want me to say a few more things about Heartbleed.

Meanwhile, this happened.

My immediate reaction, of course, was that there was no way IE shipped that early.  Windows 95 didn’t even have TCP/IP, the core protocols of the Internet, enabled by default!  Colbert had no idea what he’s Tolkein about.

Nope.  Turns out, the Colbert Report crew did their homework.   But, wait.  What?  In what universe has yet another browser bug become fodder for late night?

Hacking has become a spectator sport.  Really can’t say it’s surprising — how many people play sports every day?  Now how many people look at a big glowing rectangle?

We make the glowing box do some very strange things.

I mentioned earlier that one of the things that made Heartbleed so painful, is that it was a bug where we least expected one to be.  That is not the situation with browsers.  Despite genuinely herculean efforts, any security professional worth their salt completely expects web browser vulnerabilities to be found, and exploited, from time to time. The simple explanation is that web browsers expose a tremendous amount of attack surface to relatively anonymous attackers.

Let’s get a bit beyond the simple explanation.

It’s important to realize that web browsers, in general, are particularly vulnerable creations.  Despite the three major platforms (IE, Firefox, Chrome) being developed essentially independently, they’re all implementing the same specifications, leading to something akin to convergent evolution:  A slow language (like HTML, CSS, or JavaScript) plays puppeteer to a fast language’s object model (C/C++) via some sort of formalized translation layer (IDL for COM/XPCOM/WebkitIDL).  Take a look at this analysis of the gory details of browser internals.  See how often they just refer to browsers, in general?

There’s a reason we have very different codebases, but very similar bugs.

So why all the noise?  Why now?  In this particular case, this is the first bug after Microsoft’s genuinely unprecedented campaign to announce the end of XP support.  The masses were marketed to,  and basically told in no uncertain terms “It’s time to upgrade, the next bug is going to burn you if you’re still on XP.”  Well, here’s the next bug, and there’s Microsoft keeping their word.

(Update:  MS is issuing an XP patch after all.  Actual attacks in the field generally do trump everything else.  Really, the story of XP is tragic.  Microsoft finally makes the first consumer OS that doesn’t crash when you look at it funny…and then it crashes when I look at it funny.  Goalposts with rockets on em…)

This is also the first bug after Heartbleed, whose response somehow metastasized into the world being told to freak out and change all their passwords.

Neither of these events have anything to do with the quality of the browser itself, but they’re certainly driving the noise.  Yes, IE’s got some somewhat unique issues.  Back in the day, when Microsoft argued that they couldn’t remove IE from Windows, it was too integrated — yep, pretty much.  Internet Explorer is basically Windows: The Remix feat. The Internet.  Which makes sense, because at the end of the day browsers have long been the new operating systems.  So of course, Microsoft would basically have lots of stuff for the browser lying about.  None of that stuff was ever designed to be executed by untrusted parties, so when it ended up rigged up for remote scripting…sometimes just through the magic of COM…bad things happened.

Of course, I said somewhat unique.  Firefox and its predecessors implemented various amounts of themselves not at the C++ layer, but in JavaScript itself via a language called XUL and various interesting things reachable via the Components object.  Leaks into this trusted code have happened, with unpleasant side effects.

Where all the browsers uniformly struggle, though, is with object memory management.  Everything on a web page takes memory, and there’s only so much to go around.  Eventually, you’ve got to clear out some old objects you’re not viewing any more, to make room for more pictures of cats.  So, when can you do that?  What it comes down to is that JavaScript is really flexible, while  C++ is really fast.  We bridge the two to get the best of both worlds — the flexibility (and security!) of the former, the speed of the latter. What happens when they disagree?  What happens when the language exposed to the developer (for various values of ”developer’) still thinks there’s a picture somewhere, while C++ (yes, I know, the heap allocator, I’m trying to simplify this) has long since destroyed that picture and reused that particular memory for a video file?

Boom.  And this is pretty common.  As the great poet of our modern era, The Grugq wrote recently:

At this point, you may be feeling rather sad about the state of security in general.  The three major browsers — IE, Firefox, and Chrome — are some of the most well funded and deeply audited ongoing development efforts in the world.  If they all fail, in similar ways even, what hope do we have?

There is hope on the horizon (and through this path, we finally get back to Heartbleed).  While the browsers remain imperfect, that they work at all — let alone with ever increasing performance and usability — is nothing short of miraculous.  There is literally nothing else where it’s conceivable that you’d just wander around, executing random chunks of code from random suppliers, and not get compromised instantaneously.  (Sandboxes are things children walk into and out of with relative ease.  I’ve always wondered why we called them that.)  And there is motion towards making useful languages that are both memory safe and fast enough to do the heavy lifting browsers require — Rust being the prime example.

It’s not enough to be secure.  Hardest lesson anyone in security can ever learn.  Some never do.

Interesting things happen as JavaScript becomes a fast language — particularly the hyper-optimizable subset of JavaScript known as asm.js.  Ultimately, most virtual machines are like most sandboxes.  Not the JS VM’s — there’s been an ongoing battle to lock those down for a decade.  A VM with less to attack, that can still leverage all the optimization knowledge being absorbed into LLVM, is Interesting.

There’s a crazy project to try to run all of Webkit (the engine in Chrome and Safari, more or less) inside of JavaScript, including JavaScript itself.  Yo dawg.

There’s hope, but it comes at some price.  We don’t know what solutions will actually work, and we shouldn’t assume any of them will ever reach 100% security.  We absolutely should not assume we knew how to do security decades ago, and just “forgot” or got lazy or whatnot.  For a while it seemed like the answer was obviously Java, or C#/.NET.  Useful languages for many problem sets, sure.  But Microsoft once tried to rewrite chunks of Windows in .NET. It did not go well.  To this day, “Longhorn” will bring chills to old-school MS’ers (“Rosebud…”), and there is genuine excitement around the .NET to C++ compiler.

There are things that looked like they worked in the past, but it was a mirage.  There are things that were a mirage in the past, but technology or other factors have changed.  (Anyone remember DHTML?  Great idea, but it took a few generations before client side interactivity really became a thing.)

Who knows.  Maybe Google will someday make a sandbox that impresses even Pinkie Pie.  And perhaps I have something up my sleeve…

But expecting no bugs is like expecting no crime, nobody to die in the ER, no cars to crash, no businesses to fail.  It’s not just unreasonable.  It’s also kind of awkward to see it become a spectator sport.

(Splitting the Heartbleed commentary to a second post.)