hackademix.net

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.

An old Java vulnerability, already fixed 6 months ago in every Java implementation except Apple’s, allows remote attackers (i.e. malicious web sites) to launch arbitrary code from Safari or Firefox with full user privileges, evading the Java applet sandbox on Mac OS X.

Here’s the Slashdot’s routine Apple+Java bashing with linked source articles.

At this moment, the easiest way to protect your Mac web browser is either turning off Java globally or… you know what ;)

Update Jun 15th

Three weeks later, Apple finally patched..

In a twisted reverse April fool, Mozilla decided to anticipate the release from April the 1^st: 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 1^st 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.

Microsoft’s “clarification” on the various workarounds for the recent Internet Explorer security debacle.