Mozilla Plans Fix for CSS History Hack

Wednesday, March 31, 2010

Cross-Posted from Robert "RSnake" Hansen's blog at:

It’s with mixed emotion that I write this. The CSS history hack is soon going to close. If you look at the original Bugzilla thread this is something that Mozilla had marked as a P1 bug since 2002. You heard me right, this P1 bug has been open for 8 years. And here we are, on the cusp of an actual fix. Why do I have mixed emotion? You’d think I’d be doing back flips since we’re finally going to see an end to this. Well… the problem is we won’t.

The first problem is that this is only Mozilla - so we’re talking about a minority of all users. Secondly, of all the hacks we have at our disposal, this is just an information leakage. In fact, I recently wrote a letter, as did a handful of other security researchers, and I only marked this as third on the importance to fix out of five. Worse yet, it doesn’t actually fix the problem. There are still other timing based attacks to get the same information. So while it’s great that we’re finally fixing an 8 year old P1 bug, it’s not like the problem is gone, we’ve just removed one vector. The bad guys still have others at their disposal.

I know a lot of people will think I’m being a little harsh, but let’s take a real exploit here for a second - CSRF. You’re going to tell me, “Browsers can’t fix CSRF - that’s up to websites to fix. They should use nonces on every page.” Sure… but before this fix came out for Mozilla, they were saying the same thing about the CSS history hack - the browsers aren’t at fault - the spec is:

This might be a reasonable stopgap to check in just in case some big flap comes up, although since MS is also vulnerable, and it’s really the spec’s fault we might not come under great pressure to fix this immediately.

Yes, the spec is at fault, and yes, websites could protect themselves from the CSS history hack by also using nonces with a large enough keyspace so that computing a valid link is computationally unfeasible. Funny how both these exploits have the same fixes a) create nonces on every page on the Internet that has any sensitivity or b) fix the browser. That quote is pretty telling - without pressure from the community, there’s no way we’re going to get any of this stuff fixed because the browsers will default to whatever the poorly written spec says to do. So let’s not pat ourselves on the back too much here - it seems with every hole fixed there’s two more that pop up and even when identified they take way too long to fix. I don’t mean to harp on the Mozilla guys too much - at least they have a fix in the works. But that doesn’t change the fact that we appear to be playing a very losing game of whack a mole.

Possibly Related Articles:
Vulnerabilities Webappsec->General
Mozilla Privacy Browser Security CSS
Post Rating I Like this!