hackademix.net

Almost immediately after the news about a plugin by Microsoft compromising Firefox’s security, Mozilla reacted unleashing a “doomsday weapon”: Plugin Blocklisting, a feature introduced more than one year ago in Firefox 3 and kept quiet so far, which allows quick disablement of any problematic add-on from a central location. So this morning many of us have been greeted by an “Add-ons may be causing problems” window, announcing that the two “intruders from Redmond” had been put in custody.

Nice to see people in charge don’t hesitate to deploy such a draconian countermeasure when it’s needed, even though the Windows Presentation Foundation plugin and its .NET Framework Assistant accomplice are so much obscure (the former) and controversial (the latter) that they won’t be overly missed. Hard to imagine the same treatment being delivered to Adobe’s big ones any time soon, despite their zero day exploit rates and the fact too many browsers run outdated and vulnerable versions (BTW, did you check lately?)

However many users wonder why Windows Update and other native installers (e.g. Skype or AVG) are allowed to bypass the warning dialog which usually asks for permission before installing a Firefox add-on. The obvious objection, though, is that when you run a certain OS or launch an executable, you’re fully trusting the vendor and therefore adding further warnings would be just an useless annoyance. Notwithstanding, at least knowing that something has been added to your browser is surely desirable. I, for instance, wasn’t aware of this “Windows Presentation Foundation” thing until this incident happened. Moreover, some of these “super add-ons” are quite difficult to uninstall for the average user. Fortunately, Mozilla acknowledges these as real problems, and they’re being actively addressed.

Some time ago we advised to uninstall the Microsoft .NET Framework assistant because it was breaking some Firefox extensions.

Of course, as many noticed at that time, having add-ons from Microsoft installed into Firefox behind your back by a Windows update also expanded the attack surface of the Mozilla browser, by adding the possible (likely) vulnerabilities of Microsoft’s technology to the mix. Ironically, this is the very argument used by Microsoft itself against Google Frame.

This easy precognition is reality now. According to Microsoft,

MS09-054 addresses an IE vulnerability (CVE-2009-2529), which was discovered and presented by Mark Dowd, Ryan Smith, and David Dewey at the BlackHat conference in July. […]

A browse-and-get-owned attack vector exists. All that is needed is for a user to be lured to a malicious website. […]

While the vulnerability is in an IE component, there is an attack vector for Firefox users as well.

The reason is that .NET Framework 3.5 SP1 installs a “Windows Presentation Foundation” plug-in in Firefox.
Via this plug-in it is possible to launch XBAP, and reach this vulnerability, from within Firefox.

The Windows Presentation Foundation plugin enables “XAML Browser Applications” (XBAPs) to run into your browser. Ironically, this appears to be Microsoft’s late equivalent of Java Applets, with some ActiveX scent as a bonus (native code). Talk about lesson learned…

In order to protect yourself, open Tools|Add-ons|Plugins, select Windows Presentation Foundation, and click the Disable button.

Seven months ago Andy Steingruebl, PayPal’s Secure Development Manager, contacted me to know whether a future NoScript version could support server-side activation of its HTTPS-enforcing features, preferably with a more robust approach than the cookie-based one seen in the original Barth & Jackson’s “ForceHTTPS” proof-of-concept. Such a potential development had obvious positive implications for e-commerce businesses and secure websites in general, hardening them against session hijacking attacks. I proposed a X-Force-HTTPS response header, to be ignored if coming through an insecure connection, otherwise switching on or off the “HTTPS-only” policy for the sending host. A dedicated persistence mechanism on the client side, immune from any accidental or malicious override, was meant to overcome the obvious intrinsic limits of cookies. The discussion seemed to die there, though.

Three months later, on May the 1^st 2009, Steingruebl sent me another email, introducing Jeff Hodges, a PayPal security researcher who was preparing a specification draft for a refined “X-Force-HTTPS” header, renamed as X-Force-TLS. They were hoping to get a reference implementation in NoScript, and I would have really liked to help, but the timing could not be worse: I was already working around the clock for the first ABE public release, due on May the 25^th, and as if that wasn’t enough, just some hours earlier the Adblock Plus “scandal” had exploded all over the Internet, taking away the peace of mind required to sustain NoScript’s traditionally allegro development rhythm. So, after releasing ABE, I spent my summertime focusing on its user-driven stabilization, and the X-Force-TLS sub-project went in the fridge. In the meanwhile an experimental implementation had been provided by Sid Stamm as a standalone extension for Firefox. Sid is a Mozilla guy who’s very active on CSP as well, so this might be seen an encouraging hint to future support in the core browser.

However one week ago the security staff of a (quite easy to guess) leader Asian e-commerce player, which has been closely following the development of NoScript’s “WebAppSec-oriented” features such as ABE, ClearClick and Anti-XSS Injection Checker, asked me whether I could estimate a date for implementing a server-side switch mechanism for HTTPS enforcement, just like the one discussed earlier with PayPal. They were eager to deploy this kind of protection as soon as possible, even in October, as part of a client security campaign involving a “Safest with Firefox + NoScript” recommendation. Therefore I decided to unfreeze my own X-Force-TLS implementation and, after a quick assessment, I committed to inclusion in NoScript 1.9.8.9, scheduled for release this week. As an incredible coincidence, on day later I noticed a message from Jeff Hodges on the WHATWG mailing list, announcing the Strict Transport Security draft, a more formal and public “X-Force-TLS” header proposal, renamed again as Strict-Transport-Security and about to be implemented in the not-too-distant future by Chrome, too. So I immediately forwarded the exciting news to the interested Asian party and made the necessary HTTP header renaming in my code for NoScript 1.9.8.9, announcing its impending release.

And here we are, with NoScript providing the first public Strict-Transport-Security user agent implementation. If you’re in charge of a secure web site, please refer to the aforementioned specification to increase the reliability of your SSL deployment. If you’re a NoScript user, just keep relying on it as always, knowing that your online transactions are going to become safer during the incoming months, as adoption among secure web properties grows. And if you’re a power user and you prefer not to wait for them, don’t forget that NoScript can already force any website to use secure connections only, at your whim.

Joanna Rutkowska of Blue Pill virtualization-based rootkit fame says, among many other interesting/controversial things, that she relies on NoScript for her e-shopping hygiene.
The full 9 pages (ouch!) interview is being commented on Slashdot right now.

Many people use their hosts file for resources blocking purposes, especially against ads or known malicious sites.

Since your hosts file takes precedence over your DNS in domain name resolution, you can redirect undesired domain to invalid IP addresses, saving both bandwidth and CPU because resolved IPs are cached.

Unluckily, most information sources about this useful technique, including the Wikipedia article above, instruct the reader to use 127.0.0.1 (the local loopback IP) as the dead-end destination, rather than a truly invalid address such as 255.255.255.0. This is not very smart, especially if you installed a web server on the loopback interface (like many web developers do), because you’re spamming it with dummy requests whenever you browse an ad-laden web site.

Furthermore, I’m currently receiving several reports about ABE warnings popping up everywhere. If you read my post about ABE yesterday, you know that it ships with a built in “SYSTEM” ruleset containing just one rule which alone implements the whole LocalRodeo functionality:

# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

Such a rule blocks any HTTP request for resources placed in your local network, including localhost (127.0.0.1) and any other LAN IP, unless it is originated from your local network as well. This protects your internal servers and devices (e.g. routers and firewalls exposing web interfaces) against CSRF and XSS attacks performed from the internet.

As a side effect, though, if you’re redirecting arbitrary hosts to 127.0.0.1, you’ll get bombed by a storm of ABE warnings whenever those sites are linked from external web sites. The solution is simple: just open your host file and replace 127.0.0.1 with 255.255.255.0 everywhere it’s used to block something, but being careful to keep 127.0.0.1 on the localhost entry and other really local domains, if any.

Update:

NoScript 1.9.5.5 beta automatically suppresses notifications for the commonest case covered here (HTTP requests for a domain name resolving to 127.0.0.1 on the default port), and also introduces an option to disable all ABE notifications.