Archive for March, 2009

Hackademix.net's reader "John Drinkwater" just informed me that the BBC News' "Click" TV magazine aired yesterday (March 27th 2009) had one whole minute dedicated to NoScript (from 20'30" to 21'30", already cut and embedded below).

The general mood does not sound defamatory, but the online audio quality is not gentle enough to my untrained Italian ears :P
Would any English native speaker (better if of pure British lineage) be so kind to contribute a transcription? Many thanks!!!
Long time noscripter therube, less lazy than me, found BBC's own official transcription:

NoScript

noscript.net

Browser plug-ins like Java, Flash and Silverlight offer functionality, compatibility, and a load of other bells and whistles we have come to expect from our web browsing experience nowadays. But they have their downsides too.

You'll no doubt have heard talk about malicious code embedded in certain plug-ins, so if you want to be sure of being totally safe online, this nice little plug-in I found for Mozilla-based browsers should help you sleep better at night. It physically blocks any codes from running unless you give your express permission to do so.

It can also be handy if you're running on a slow connection and don't want loads of movies and animations trying to launch into the page you're accessing. Equally, many marketing organisations will run applets in the background that tell them when you're using their site, and how.

Download and install take literally seconds and then you'll see a noscript icon in the bottom right hand corner of your browser window. Each time you visit a new web page, if it tries to load any scripts the applet will block these and alert you. Clicking the noscript icon now will allow you to block or allow certain scripts on the page. Individual panels in the web page which are blocked can also be right clicked to allow you to set the permissions for that particular script.

In a twisted reverse April fool, Mozilla decided to anticipate the release from April the 1st: it's today, folks.

As you may already know, it fixes:

  1. the mysterious flaw exploited by "Nils" at the CanSecWest Pwn2Own contest, at the speed of light (the IE8 and Safari vulnerabilities revealed the same day are still unpatched);
  2. the XLST processing bug which I wrote about yesterday.

Current NoScript stable version (1.9.1.4) prevents the XSLT crash from be exploited for malicious purposes, by defeating heap spray attempts which require JavaScript, Java or Flash. That's very good, but not enough: a crash is still annoying even if it cannot install malware, notwithstanding session restore.

Since we can (un)safely assume this is not the only potentially exploitable XSLT parser bug hanging around, today I released the NoScript 1.9.1.5 development build, featuring specific XSLT protection: XSL stylesheets won't be processed unless they're from a trusted source and their parent document is trusted as well. This countermeasure effectively prevents malicious sites from crashing (or, worse, compromising) your browser through this or any other XSLT bug discovered in future. As NoScript's motto says, defeating "exploitation of security vulnerabilities, known and even not known yet!" :)

A Firefox 3.0.8 "high-priority fire drill security update" is on its way, likely to be released by the middle of next week (April the 1st at most, jokes aside). The reason is an emergency patch for a critical vulnerability irresponsibly disclosed by Guido Landi. I feel a bit guilty about it because Mr. Landi is Italian like me -- not that here in Italy we lack reasons for being ashamed...

Beware the PoC: it will crash Firefox on Windows, Linux and Mac OS X even if you've got NoScript. However this crashing bug, like the vast majority of them, is not exploitable if you've got JavaScript and other active content disabled on the attacker site, because reliable exploitation requires scripting to "spray the heap", i.e. to inject the malicious payload at the right places of your memory for execution.
Therefore you can easily survive until the automatic update kicks in, if you don't mind the possibility of an annoying but not dangerous crash (thanks, session restore!) ;)

On a side note, it's time to update Java as well: yet another bunch of critical vulnerabilities, several of them exploitable in your browser. Business as usual...

Important updates here.

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 632 access attempts in the last 7 days.