hackademix.net

As you probably know, the details about the paradoxical behavior of the Internet Explorer XSS Filter, introducing XSS vulnerabilities of its own on otherwise immune web sites, which we hinted at some months ago, have been revealed by Edoardo “Sirdarckcat” Vela and David “thornmaker” Lindsay recently at the Black Hat Europe conference, in Barcelona (on a side note, looks like Sirdarckcat enjoyed his stay there so much that he decided to remotely hack a certain volcano…)

I’ve been quite disappointed by the preamble of their paper, which calls IE8’s XSS filter a new type of defense and a somewhat novel approach (before bashing it), when we all know that NoScript came first. Sirdarckcat personally apologized, blaming Lindsay for this and other “pro-big-players” bias, such as the decision of omitting, from the comparative table in their slides, Sirdarckcat’s opinion about NoScript’s being the safest among the in-browser filters and the hardest to bypass.

Notwithstanding, the technical core of this research is very worth reading, if you’re interested in XSS attack and defense techniques.

After the Black Hat debacle got echoes in the press, David Ross, the main XSS Filter engineer at Microsoft, published a Guidance on Internet Explorer XSS Filter document on the Microsoft Security Response Center website, announcing a not better specified “patch” coming in June (mmm, two whole months? need some help?) and making two interesting statements:

In the case of the Internet Explorer XSS Filter, researchers found scenarios that are generally applicable across XSS filtering technologies in all currently shipping browsers with this technology built-in.

This essentially means just two, IE8 and Chrome… but wait, Chrome doesn’t ship with its XSS Auditor enabled anymore because it was dog slow!
Hence the final recommendation by Ross…

Overall we maintain that it’s important to use a browser with an XSS Filter

… can really mean one thing only: Microsoft maintains that it’s important to use Firefox with NoScript :)

Time to revisit putting SSL in perspectives, since you can’t even trust CAs themselves.

I took a cursory look at Perspectives add-on’s code, and it cries for a compatibility & performance rewrite (oh, if I could just find the time!), but it’s still the best patch we can currently throw at this problem.

As you may already know, now that Mozilla has fixed the recent Firefox 3.6’s “0-day” at light speed and vulnerability details are public, the feature protecting NoScript’s users against this by default was Forbid @font-face.

The @font-face CSS rule allows web authors to download online typefaces (so called “web fonts”) on the fly, enhancing the rendering of their pages’ text:

By allowing authors to provide their own fonts, @font-face eliminates the need to depend on the limited number of fonts users have installed on their computers.

If you’re wondering why NoScript — for a long time now — has been treating web fonts the same way as other “active” embeddings, such as plugin content and HTML 5 media elements, here’s an excerpt of an email which Mike Perry (Mr. Torbutton) sent me past year, eloquently advocating this treatment:

It really worries me that the FreeType font library is now being made to accept untrusted content from the web.

The library probably wasn’t written under the assumption that it would be fed much more than local fonts from trusted vendors who are already installing arbitrary executable on a computer, and it’s already had a handful of vulnerabilities found in it shortly after it first saw use in Firefox.

It is a very large library that actually includes a virtual machine that has been rewritten from pascal to single-threaded non-reentrant C to reentrant C… The code is extremely hairy and hard to review, especially for the VM.

The reason I don’t want to do this blocking in Torbutton is because Torbutton is only about protecting users from privacy risks, not general security risks. Users who want enhanced security are encouraged to use your extension and others on our FAQ page.

Don’t panic.

Bürger-CERT (”German’s official cyber-security response team”) is warning users against using Firefox until version 3.6.2 (scheduled on March the 30^th) is out, on the assumption that Secunia SA38608 needs to be considered a 0-day threat, but:

1. There’s no evidence of this vulnerability being exploited in the wild, even though paying customers of the VulnDisco security product have been given access to a working exploit since February the 1^st.
2. A patched Firefox release candidate is already available, so if you’re really scared or impatient you can get it here.
3. As almost always happens, NoScript* has been protecting its users since day 0, keeping its promise of preventing exploitation of security vulnerabilities (known and even not known yet!).

* in its default configuration, and even better in its full content blocking mode.

Update 2010-03-23

In the meanwhile, Mozilla decided to go through the effort of anticipating Firefox 3.6.2 by one whole week for the greater good, so if you haven’t seen the “Available update” message yet, just use Help|Check for updates now.

Now that vulnerability details are not embargoed anymore, I can add that exploitation required the browser to load a specially crafted web font. The relevant NoScript feature protecting against this is NoScript Options|Embeddings|Forbid @font-face, which is checked by default.

Interesting idea by Samy (yes, that Samy):

Here is a proof of concept in what I’m calling NAT Pinning (”hacking gibsons” was already taken). The idea is an attacker lures a victim to a web page. The web page forces the user’s router or firewall, unbeknownst to them, to port forward any port number back to the user’s machine. If the user had FTP/ssh/etc open but it was blocked from the router, it can now be forwarded for anyone to access (read: attack) from the outside world. No XSS or CSRF required.

In short, he exploits a smart mechanism in modern network equipment, which graciously and “magically” NATs on the fly arbitrary ports when certain handshake patterns are detected in outbound traffic, allowing (usually older) protocols which require a “call back” connection (like FTP, IRC or SIP) to work properly.

Good news is that ABE can prevent exploitation without hampering the useful functionality. If you’re concerned about this issue, you just need to open NoScript Options|Advanced|ABE and edit the “USER” ruleset, adding the following rule:

# NAT Pinning blockage (blocks outbound HTTP traffic to unlikely ports)
Site ^https?://[^/]+:[0-35-7]
Deny

Bad news is that Java, Flash, Silverlight and maybe other plugins can open raw sockets bypassing any browser control, including ABE. Just another reason to keep them at bay.

Thanks to Thoughtcrime for bringing this to my attention, and to Samy for the chat we had this afternoon.