Archive for March 9th, 2009

About one year ago, a Firefox 3 beta appeared to eliminate a long standing XSS hazard, by preventing 3rd party XBL from being loaded and executed in a content document.
This enhancement, while going in the right direction, received some skeptical comments because at the same time the ability of specifying inline XBL bindings using data: URIs had been introduced, opening new exploitation venues. The data: XBL thing was obviously an oversight: in fact, Firefox 3 stable didn't allow it anymore, except "from chrome code (in other words, from the application or an extension)”.
However these mitigations had been anticipated and surpassed by a configurable cross-site XBL protection feature introduced a few months before by NoScript, whose default settings were more restrictive and effective than the new browser built-in XBL policy, even when Firefox 3.0 stable seemed to get it right. Seemed.

According to the MDC documentation,

The normal same-origin policy is used for web sites; they can only link to XBL files on the same domain, or within the chrome.

This statement tricked most readers (including myself, some sla.ckers and probably even hardcore Mozilla hackers like Jonas Sicking) into believing that everything was fine and dandy. Except that we've just learned (the painful way) that a more precise formulation describing what actually happens should have been:

Web pages and stylesheet can only link to XBL files in the same domain as the linking file itself.

In other words, if I open a good.com web page including a stylesheet from site evil.com, which in turn links a XBL file from the same evil.com domain, Firefox 3 lets everything work smoothly (the stylesheet and the XBL being same-origin), with the net result that XBL scripts from evil.com are allowed to run on good.com (the very "bad thing" which Firefox 3 was supposed to prevent).

I must admit that if I was not committed to supporting Firefox 2, after reading the misleading documentation above I would have likely dropped NoScript's own cross-site XBL protection, which actually blocks any cross-site XBL (i.e. XBL from a domain different than the loading document) except from chrome: the way the documentation falsely seemed to imply and the only effective way from a XSS mitigation standpoint. Blessed be FSM the Merciful for inspiring backward compatibility concerns in my unworthy soul ;)

Unfortunately for non-believers, "bad guys" noticed this theory/practice discrepancy (or, more likely, just empirically realized that some old malicious XBL code still worked against Firefox 3) and are exploiting it in the wild, together with a similar well known Microsoft proprietary "feature" (dynamic properties) allowing JavaScript to be run from stylesheets in IE.

Specifically, The Register's Dan Goodin wrote about an eBay scam (originally reported by Cefn Hoile) based on this XSS weakness. Of course, rather than browser flaws, there's a fundamentally broken web design choice here to blame: allowing unfiltered user-provided stylesheets to be embedded in "trusted" content is very dangerous independently from JavaScript execution, because an attacker could modify the appearance of the page in malicious ways, e.g. for Clickjacking purposes, or even access some page content (password fields!). But on the other hand, preventing stylesheets inclusions from executing 3rd party malicious scripts (like Opera, Safari and Chrome do) actually reduces the attack surface, which was the apparent intention of the original Firefox 3 XBL policy change.

If Microsoft, according to Goodin, won't do anything about this issue, Mozilla developers are already working to a fix. In the meanwhile you can rely on NoScript, one step (more than one year, actually) ahead as usual...

Bad Behavior has blocked 1379 access attempts in the last 7 days.