Archive for the ABE Category

Universal XSS 0day in Adobe Flash controlled users’ Web accounts:

As useful as sandboxes are in restricting potentially buggy code to a small part of the operating system, they do nothing to minimize the damage that can be done by attacks that exploit universal XSS flaws, researchers said.

I was already preaching this four years ago: the more our assets move “in the cloud”, the less traditional security measures, meant to protecting just your local system, suffice.

The battlefield is the web now, and there’s no coming back…

I’m pleased to announce the availability of NoScript 3.0a8 for mobile devices. Tested on Firefox for Android, it should work on Maemo too.

This is the first feature-complete mobile version of NoScript. In other words, it provides all the major security features of its desktop counterpart which make sense on a mobile device:
NoScript for Mobile Options

Important usability-oriented features — such as Script Surrogates or the ability to emulate JavaScript-only navigation on sites where scripting is blocked — have been ported as well, and other have been developed from scratch. For instance, on first run NoScript offers new users the ability to choose its default configuration among 4 presets which may be changed later:

  1. Easy Blacklist (you pick untrusted sites where JavaScript and plugins must be blocked)
  2. Click To Play (plugin a and audiovisual content is blocked until you click a placeholder)
  3. Classic Whitelist (you pick trusted sites where JavaScript and plugins can run, similar to the default NoScript 2.x setup)
  4. Full Protection (like “Classic Whitelist”, but all the embedded content is blocked until you click, even on trusted sites)

Furthermore, while the in-page permission UI has been greatly simplified and optimized for touchscreen consumption, NoScript for Mobile In-Page Permissions UI the underlying engine has been redesigned to allow deep per-site customization at the single permission level (e.g. making Flash permanently work by default on site X but not on site Y, even if JavaScript is allowed on both, or causing restrictions on a certain embedded object to depend on its parent page’s address). These fine grained permissions will be configured through a new desktop UI (under development, slated for inclusion in the first cross-device NoScript 3 beta) and synchronized safely via Firefox Sync across all the PCs, tablets and smartphones where NoScript is installed.

Talking about synchronization, you can already share your NoScript settings among your mobile devices (just check the “Enable Remote Sync” option), but you’ll need to wait for the aforementioned cross-device beta to include your PC in the synchronization pool.

Last but not least, NoScript 3 doesn’t require a browser restart on installation and updates, which means that hot fixes for new security threats can be deployed in a more effective, timely and convenient way.

And here we are: NoScript users can now bring to their smartphones and tablets the same secure browsing experience they enjoy on the desktop.

It’s not been easy, and there’s still a lot of work ahead to merge into the desktop version the many under the hood enhancements that this full rewrite of NoScript’s internals brought us as a welcome side effect, but this is probably the most important milestone in NoScript development since the XSS filter invention. So let’s celebrate and thank from the bottom of our heart the people who made it possible: the NLNet foundation which believed in this project since the beginning, and all those individuals, institutions and companies relying on and contributing back to NoScript.

According to Mark Finkle, who comments Daniel Glazman’s reply to Wladimir Palant (and the discussions goes back many hops yet)

[…] there are two classes of binary XPCOM components:

  1. XPCOM wrappers around 3rd-party binary libraries: We use this model for exposing external binary functionality into JavaScript so add-ons and applications can access the libraries. Using js-ctypes should provide a simple, non-breaking way to expose the libraries. You create a simple JavaScript wrapper in a JavaScript XPCOM component. We need more examples of using js-ctypes to do this, but it works.
  2. Pure binary XPCOM components built only using the Mozilla platform: Sometimes the functionality you want to expose is actually locked away in the Mozilla platform itself. Maybe there is no public nsIXxx interface or the existing interface has a [noscript] attribute on a property of method. This model shouldn’t be required anymore, in my opinion. Mozilla is pushing JavaScript based components and we should be exposing as much as possible to chrome JavaScript. I would encourage add-on developers to file bugs and lobby to expose binary-only parts of the Mozilla platform to chrome JavaScript.

I fully subscribe to Mark’s opinion about the second category, but unfortunately this is not just as simple as removing the [noscript] flag from interesting APIs (and introducing some wrapper types to make it possible).

What about subclassing a platform component in JavaScript? Of course you cannot as long as its interface expose any [noscript] member, but you cannot either if it happens to be marked as thread safe. That’s the case of the DNS Service, which can be called from any thread. I’ve considered wrapping it in order to satisfy a strict requirement of ABE’s (intercepting HTTP requests after DNS resolution but before any data is sent to the web server) in a less hackish way than today, but this would currently require building a XPCOM binary for each supported native platform. That’s a trouble I’d gladly spare myself, and Mozilla’s making it unsustainable anyway. So, does Mark’s statement imply that the relatively recent ban on multi-threaded JavaScript might be reconsidered? Is this even possible in this brave JSCompartment new world?

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)!
Browserscope Security Test
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!

Senior NoScript community contributor Grumpy Old Lady finally sent me a link to these notes, taken live at BlackHat USA during Graig Heffner’s “How to Hack Millions of Routers” talk, and to the tool he released, allowing to remotely control the many models of routers found vulnerable to a specific kind of DNS Rebinding attack.

Since I couldn’t attend the L.A. conference, I’ve been anxiously in search of something like that to confirm al_9x’s speculative forecast, i.e. that the exploited vulnerability was about routers exposing their administrative interface to the LAN on their WAN IP (even if remote administration is explicitly disabled), and now I’m delighted to find he was entirely correct!

Of course I must be happy, because I don’t need to rush out another ABE feature like the WAN IP protection which I baked inside NoScript 2.0 last week, and because my own home router had been vulnerable as well :)

Some clarifications are still needed, though.

Among the mitigations reportedly enumerated by Heffner (even if he had previously claimed that NoScript couldn’t help), there’s

Use NoScript (disable javascript?) Maybe not practical to most users

Now, it is true that Heffner’s attack fails if the attacker’s domain, bound on the fly to user’s WAN IP, is not allowed to run JavaScript (very likely, when you use NoScript). This means that most users of older NoScript versions (1.10 and below) were already protected against Heffner’s tool and this kind of “XSS via DNS Rebinding”.

However, like for many other “emerging threats”, NoScript provides a specific protection against this class of vulnerabilities (in this case via its ABE module), completely independent from script blocking: in other words, it just works, no matter if you decide to keep JavaScript, plugins and frames enabled everywhere (”Allow Scripts Globally“). There’no reasonable excuse to renounce this protection, since it does not imply the alleged “non-practicality” of enabling JavaScript selectively.

So, since security experts themselves sometimes seem confused about NoScript’s real “convenience vs security” tradeoffs, taking for granted that all the security it offers depends on and requires script blocking, recapping here a (non exhaustive) list of attacks blocked by NoScript even in “Allow Scripts Globally” mode may be useful:

  1. XSS, thanks to its “Injection Checker”, the first anti-XSS filter ever released in a web browser.
  2. Clickjacking — NoScript’s ClearClick feature is still the only effective protection entirely implemented inside the browser and requiring no server-side cooperation.
  3. CSRF (and especially, by default, cross-zone attacks against intranet resources) via the ABE module.
  4. MITM, courtesy of HSTS and other HTTPS-enhancing features

These are just some of the many additional protections provided by NoScript which do not depend on scripting being disabled. So next time you hear people saying “yes, browsing with NoScript is safer but having to pick trusted sites to run JavaScript is a pain“, point them to these good reasons for running NoScript, even if they give up the extra security provided by plain old script blocking.

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