Firefox 3.6.13: damn you, corner cases

Today's release of Firefox 3.6.13 fixes bug 602780 (CVE-2010-3774) - an interesting problem I originally reported to Mozilla in October. It's a fun one, so here's a quick recap of what it is about.

As you may recall, one of the more significant shortcomings of the same-origin policy is that it does not give any guidance on handling documents with no inherent origin associated - that is, it fails to account for all the content coming from about:, data:, file:, and similar pseudo-URLs. Consequently, early implementations of this security model simply allowed all origin-less frames or windows created by one site to be accessed freely across domains - an empty host name string equals any other empty host name string, after all. As can be expected, this approach proved to be a bad idea - and since then, quite a few necessary improvements have been made. Today, every pseudo-URL should either inherit its origin from the parent document, or be assigned a completely unique one.

Alas, in Firefox, some of this logic would not work as expected in a handful of corner cases; this problem probably traced back to a minor code refactoring somewhere in 2008. The vulnerability would not trigger with about: or data: subframes on legitimate sites - and therefore, would not affect normal browsing - but with some minimal effort, it could be leveraged by malicious sites to access and modify the contents of internal browser pages, such as about:config, about:neterror, and so forth.

The consequences of access to about:config can be disastrous, but in this case, are somewhat mitigated by the fact that under standard operating conditions, random Internet-originating content can't open that location directly. In other words, the vulnerability could not be exploited without soliciting a degree of user interaction.

The story with pages such as about:neterror is a bit more interesting, though: in modern versions of Firefox, these documents are shown in place of the old-fashioned modal dialogs to indicate navigation errors. Crucially, when this happens, the content is displayed with the intended destination URL, rather than the true origin (about:...), shown in the address bar. With this simple trick in mind, the attacker can inject his spoofed content into a window where the address bar incorrectly points to an unrelated domain of his choice. Whoops!

If you haven't upgraded to 3.6.13 yet, check out this bombastic demo to see the attack in action.