hackademix.net

NoScript 2.0.4 has been released yesterday, with some bug fixes and one main addition: strict X-Content-Type-Options: nosniff enforcement.

NoScript, for a long time, had already being enforcing content type checks on cross-site Javascript and CSS includes, and recent Firefox versions introduced similar built-in mitigations, albeit limited to stylesheets, in order to mitigate CSS-based data theft.

Nevertheless, X-Content-Type-Options offers a nice opportunity to further hardening, by allowing web sites to opt-in for the strictest checks, on more file types and also same-domain, in a theoretically compatible way.

A side effect of this addition is that Firefox 4 + NoScript now scores 14/16 on Browserscope’s Security Test, in “Allow Scripts Globally” mode (i.e., without blocking any JavaScript or active content)!

For those who don’t know it, Browserscope is a project which aims at profiling and comparing browser capabilities, with a special eye for security features.

By comparison, only Google Chrome boasts a higher score of 15/16, because it supports both the HTTP Origin Header and the HTML 5 Sandbox Attribute, which are not implemented yet by Firefox nor by NoScript. For the curious, “vanilla” Firefox 4 nightlies stop at 11/15 (even if you’re going to read 12/15 because of a XSS test bug), Firefox 3.6.12 + NoScript is at 13/15, while disabling NoScript makes it fall down to 9/16 (reported as 10/16 because of the aforementioned bug).

However, a fair comparison would need to cover also Content Security Policies, a very powerful and flexible security technology developed by Mozilla (test should be added soon, it seems) and countermeasures for cross-zone CSRF attacks (e.g. against routers), which are currently provided by NoScript and, partially, by Opera (Mozilla is working on something, too)*. If and when these features get tested, Firefox 4 + NoScript will lead at 16/18, followed by Chrome at 15/18.

That said, I’d really love to see Origin and Sandbox implemented natively by Firefox, for a perfect 18/18. Which is, I guess, the real raison d’être of Browserscope: getting good stuff implemented everywhere by the power of childish envy ;)

* I won’t advocate including tests for other non-blocking security features provided by NoScript, such as ClearClick anti-Clickjacking, because they’re not suitable for web-based automation.

Update 2010-11-13

Firefox 4 + NoScript scores 15/17 now!

I know, it’s getting ridiculous, so here’s a news report about the new unpatched vulnerabilities being exploited in the wild, and here’s my old commentary about the old ones, which is still valid as it will always be, I’m afraid, until Adobe’s plugins finally fade away…

The Problem

You’ve probably read in the news about a Firefox extension called “Firesheep”. It has been developed by Eric Butler and recently presented at ToorCon, pretty much to demonstrate a rather obvious thing: if a website which handles passwords or other sensitive bits doesn’t enforce HTTPS encryption all over its domain, rather than just on login pages like many do (including Facebook and other popular social networks), your data can be easily sniffed and reused by malicious third parties. Furthermore, under specific circumstances (e.g. when you use a TOR), a MITM attacks can silently redirect you to a fake HTTP version of the site, and there’s not much a web site can do about this without client’s help, other than consistently using HTTPS-only cookies.

HSTS To The Rescue!

What you may or may not know is that a technology called HSTS (HTTP Strict Transport Security) has been designed, mainly after Paypal’s input, in order to help websites make HTTPS setup more reliable and safe against hijacking attacks. HSTS has been implemented by NoScript and by the Chrome web browser more than one year ago, and it’s currently shipping also in Firefox 4 betas and development builds.

HSTS is a passive security enhancer, though, because it needs websites to opt-in by sending a Strict-Transport-Security HTTP header, which asks the browser to automatically “upgrade” every subsequent request for the same site to secure connections (HTTPS), no matter if it had been initiated as plain HTTP.

Being Proactive

Since HSTS is really simple and easy to understand, it would be wonderful if every web site supporting HTTPS deployed HSTS too. Regrettably we’re not there yet: www.paypal.com (quite obviously) and secure.informaction.com are among the very few which already do, but for instance addons.mozilla.org currently doesn’t, nor does Google itself.

Fortunately NoScript, for more than two years now, has also allowed us to manually select the web sites which we want to browse via HTTPS only, by adding them in the NoScript Options|Advanced|HTTPS panel. Of course not all the web sites like to have HTTPS pushed down their throats, so you should pick only those already supporting HTTPS, and still may expect a tiny few of them to misbehave. However your online banking, your webmail and the aforementioned addons.mozilla.org are probably great candidates to be added in NoScript’s “force HTTPS” list right now.

Yesterday Adobe rushed out a security update (version 10.1.85.3), one week in advance on the announced schedule, patching a critical vulnerability that has being exploited in the wild for more than one week.

As usual, users of the latest stable Firefox version on Windows are plagued with an awful manual update process, involving the installation of a ridiculous “Adobe DLM (powered by getPlus(3))” extension (forcing an extra, useless, browser restart), whose only function seems to be displaying additional banners during the download.

Even worse, this time looks like Adobe made going through this process actually impossible, on my system at least, because of a mismatch between the DLM plugin version they automatically offer, i.e. getPlusPlus for Adobe 16290, and the version actually required for downloading the Flash update with their markup:

<embed type="application/getplusplusadobe16291"
pluginspage="http://platformdl.adobe.com/NOS/getPlusPlus/1.6/gp.xpi"
service-url="http://get.adobe.com/flashplayer/webservices/dlm/"
return-page="http://get.adobe.com/flashplayer/completion/dlm/"
itemid="Flash_Player_10.1_for_Windows_-_Other_Browsers"
core-product="flashplayer" dlmbanner="on" language="" os="" height="1" width="1">

As you can see, the required version is 16291, rather than 16290.

Fortunately the actual direct download URL is not impossible to discover, for instance by dinamically replacing “16291″ with “16290″ with a bit of javascript: magic in the address bar and sniffing the network activity.

So, if you’re stuck like me or you just don’t want to install this getPlusPlus crap, you probably want to use this direct link :)

The Adobe Flash Player, current version 10.1.82.76 and below, is affected by a critical vulnerability which, according to Adobe’s Security Advisory APSA10-03, is being actively exploited in the wild. A patch won’t be available until September the 27^th, which means the 3 or 4 Flash users out there are left in the cold, under attack for two weeks at least.

In the meanwhile, the only mitigation measures available are either disabling Flash outright or using NoScript.
At any rate, relying on the “FlashBlock” extensions for your security is not a good idea, neither on Firefox nor on Chrome: these toys are great against annoyances, but too easy to circumvent to be hacker-proof. Unfortunately you can always find naive advices in the press…

If you believe that building your whitelist of websites trusted to run scripts is too tiresome, please consider this: after 2 or 3 days of training, NoScript will know enough about your browsing habits to amost vanish in the background. Moreover, latest versions feature a true “one click” UI which further reduces your initial effort, because now the contextual menu is shown as soon as you just hover over NoScript’s icon, allows you to switch multiple permissions at once and disappears as your mouse moves away. However, if you’re an irreducible who wants JavaScript to run free everywhere, you can still emulate a safer “FlashBlock mode” by using NoScript’s (not recommended) Allow Scripts Globally command after having checked NoScript Options|Embeddings|Apply these restrictions to trusted sites as well.

Talking about mitigation, I heard much fanfare (even on ./) about Microsoft’s Enhanced Mitigation Toolkit (EMET) 2.0 being able to prevent exploitation of another 0 day affecting Adobe Acrobat Reader. Unfortunately at this moment I had no success at downloading this fabulous tool by following the available links, but this probably just means I’m low on caffeine. Could anybody point me to a working and trusted EMET 2.0 download source? Update: the link from the MS blog was actually broken this morning, but now it’s reachable as pointed out by a commenter.

Update 2010-09-20

Adobe rushed out version 10.1.85.3 one week earlier than scheduled to patch this hole.