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...

6 Responses to “Cross-Site XBL Returns from the Dead”

  1. #1 Aerik says:

    I knew I always kept noscript.forbidXBL to 5 for a reason. And I allow my AdBlock Plus to apply to chrome: URL's, and I block all XBL except for a few chrome XBL addresses.

    In fact I find no real problems with turning adblock's about:config preference extensions.adblockplus.whitelistschemes completely blank, and only whitelisting exact things I need, applied only to the specific websites I need them to work on. I also forbid chrome:, data:, file:, and resource: in NoScript. I'm paranoid that way, but it doesn't hurt anything at all to do it.

  2. #2 Tom T. says:

    Praise be to the Spaghetti Monster! Giorgio, *please* maintain full compatibility with Fx 2.20 for as long as you possibly can. There are many users, including myself, who refuse Fx3 as being unproven (as you've just proved!), more complex, useless and distracting graphics, etc. There are extensive threads at Mozillazine to this effect, or it would be simple to check their stats on how many F2s are still running (by the number of nag screens they pop up to tell you to upgrade). Thank you so much!

    @ Aerik:
    For the sake of us dummies, can you please list specific instructions for each change, and what the effect will be? For example, I see NSForbidChromeScripts and ForbidData, but don't immediately find "file" or "resource". And XBL seems to default to 4. I don't know what the levels mean, but if 5 is safer, I'll do it, but what will change in the browser's appearance and behavior? You seem to have a very good handle on maximum lock-down; please share your complete setup and results with the codely-challenged.

    As far as being "paranoid", one of my favorite quotes from the movie "Conspiracy Theory" is "I'm only paranoid because they want me dead." In other words, you're not paranoid if you're right, which you are. Thanks!

  3. #3 Basti says:

    NoScript saves the world, again. Why ever it has to... Although you can't say it's Firefoxs' fault I hope 3.1 and following 3.2 will be safer by default. FF is very good as you all can see: they are fixing it.

    NoScript + Brain help a lot until the internet is safe... (a little sarcasm, it will never be)

  4. #4 Felipe says:

    Hey Giorgio, a bit off-topic, but you really should see that! The folks from Mozilla Brasil made a couple of videos asking people why they use Firefox, and many people cited security, web-standards, add-ons, etc. NoScript was cited many times. (The videos were made on a geek event, Campus Party)
    But there was definitely one *enthusiastic* fan of NoScript =) Take a look: http://vimeo.com/3292638 It's in Portuguese, so if you want just go to the very end of the movie, around 2:45.

  5. #5 esquifit says:

    I'd noted this fact about one year ago when switching from FF2 to FF3. I was using a XBL binding from Stylish to embed scripts in web pages 'à la Greasemonkey', and this ceased to work in FF3. Boris Zbarsky at mozilla.dev.tech.xbl told me about the change in the policy. Then I noticed that a simple workaround was to have a style which would consist of an @include statement, and the @included stylesheet (hosted in my domain) would contain the XBL binds in the same domain. I blogged about that in http://esquifit.blogspot.com/2008/08/enhancing-content-with-xbl-2.html. Now know I should have reported this as a bug, but I felt comfortable with my 'solution'. I can live with the NS protection, hopefully the mozilla guys won't 'over-fix' this.

  6. #6 Pat says:

    Hi I'd like to know if it's possible to read the web page html code and apply a filter of if's and elses to remove or filter certain runs of code?

    My problem is that participate in a web forum where I get into a lot of heated arguments with a certain two posters. I'd like to make my own filter that works to simply filter out comments by those two people and not display them in my browser. I know it sounds juvenile, but I'd like to do this for myself as well as friends who blog on the same forum and are constantly baited and cajoled, and the moderator refuses to do anything about it.

    Would I need to hack the chrome source code, or is it possible to add a script to usercontent.css? Is that even possible? Yes, I do need some general advice and pointed in the right direction. Thanks for your time

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