Firefox fixes CSS-based cross-origin theft issue

Firefox just released version 3.6.7 of their excellent browser, and it fixes this:

http://www.mozilla.org/security/announce/2010/mfsa2010-46.html

This leaves 4 of the 5 major browsers with fixes (more on this in an upcoming post), which is my threshold for documenting a little tweak to exploitability. It is partially inspired by Gareth Heyes' attack on E4X using character set overrides. For interesting background reading, see:

http://www.thespanner.co.uk/2009/02/24/inline-utf-7-e4x-javascript-hijacking/

Turns out, the same character set override applies to loading cross-origin CSS via the <link> tag. This means that you can use UTF7 in Firefox to get around one of the key restrictions in the original attack. Specifically, you can force the CSS to be interpreted as UTF7, which makes injecting either type of quote (single or double) trivial to do without it getting escaped. Of course, the larger newline-related restriction remains in sane browsers.

Also, it's worth documenting how the character set override works. Interestingly, in all the browsers I tested (Chrome, Firefox, Safari) -- any character set specified in a site's HTTP headers has a higher precedence that the attacker's attempted override in the <link> tag. Useful. You should always specify character sets where possible. It has also defended against other previously unknown attacks in the past.

One final note is that not all browsers support UTF7. Chrome for example does not. I'm sure no-one would shed tears if UTF7 died.

Fixing responsible disclosure

Today I had the pleasure to post:

http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html

It is co-signed by some of my awesome fellow engineers who personally believe in what is written.

Recent discussions and debates have shown that "responsible disclosure" is broken. It is badly named and ill-defined. Possibly the worst problem with responsible disclosure is that is permits known critical vulnerabilities to go unfixed for months or even years. As many commentators have pointed out, that is hardly "responsible". We've also seen what happens when we go down that route.

The simple proposed fix is to use reasonable deadlines to encourage things in the right direction. 60 days for critical issues. ("critical" in the genuine unsandboxed & arbitrary code execution sense, not "critical" just because some news article or researcher is overstating things).

Speaking personally about my work on securing the Chromium browser: I'd be mortified if I learned of a SecSeverity-Critical bug and it took me over 60 days to protect my users from it. It's not always possible to move this fast, but for one of the few critical bugs I found, the timeline shows it was not only fixed but also installed across the user base in about 6 days.

Related reading:

• http://lcamtuf.blogspot.com/2010/07/rebooting-responsible-disclosure.html


• http://taviso.decsystem.org/grandma.html

More money for critical Chromium security bugs!

We've seen who is $1337 but who is $3133.7 ?

I just launched this:
http://blog.chromium.org/2010/07/celebrating-six-months-of-chromium.html

I've really enjoyed launching and now refreshing this program.