Protection from http://www.securityfocus.com/bid/34235/info

[Riccardo]

Hello,
can noscript protect from:
http://www.securityfocus.com/bid/34235/info

I tried the proof of concept through a local file but even putting file:// out of whitelist still triggers the bug.
Is there a way to be protected against it?
Thanks,
Riccardo

[Alan Baxter]

Is there a way to be protected against it?

Yes. Don't allow JavaScript on any but trusted sites, and then, only when absolutely necessary.
http://hackademix.net/2009/03/26/lock-d ... e-weekend/

[Giorgio Maone]

As I wrote in the article linked by Alan, the crash still happens because the XSLT gets parsed, but it's not exploitable because with no JavaScript (or other active content) enabled the attacker can't use any of the well known "Heap Spray" technique required to inject the actual malicious code in the random memory area where such a crash makes Firefox's program counter jump.

Furthermore, since a crash is always an annoyance (albeit non-exploitable and notwithstanding session restore), and since other XSLT bugs are likely to be discovered in the future, next NoScript development version (probably out later today) will consider XSLT as active content, blocking XSL stylesheets on untrusted documents and/or from untrusted sources.

[therube]

Just to point out ...

securityfocus only lists FF3. But FF2 & FF3.1 (aka FF3.5) are vulnerable too.

The (generally acknowledged) bug is, Bug 485217: Exploitable crash in [@txMozillaXSLTProcessor::TransformToDoc ]. In actuality (or as it now stands) the actual fix will be whats included (& is already in FF 3.0.8) which is the fix for Bug 485286 (which for security reasons is not accessible to most), an alternate fix to 485217.

[GµårÐïåñ]

Thank you Giorgio, I think that consideration will be a worthwhile addition to NoScript. Thanks for your hard work as always.

[Giorgio Maone]

Thank you Giorgio, I think that consideration will be a worthwhile addition to NoScript. Thanks for your hard work as always.

XSLT protection is already in latest development build, and Firefox 3.0.8 should also be on its way, since the update date has been anticipated to today.

[therube]

XSLT protection

But will only work if file:// is not allowed?
(Or maybe, will only work locally if file:// is not allowed?)

[GµårÐïåñ]

XSLT protection is already in latest development build, and Firefox 3.0.8 should also be on its way, since the update date has been anticipated to today.

Then more appropriately, thank you +1

[GµårÐïåñ]

But will only work if file:// is not allowed?
(Or maybe, will only work locally if file:// is not allowed?)

Cool then, I never have file:// allowed and only give it temporary permission when I am testing something I am working on myself. Thanks.

[Giorgio Maone]

XSLT protection

But will only work if file:// is not allowed?

It will work if the attacker's site is not allowed. In other words, I'm regarding XSLT just as it was scripting, since XSL has been demonstrated Turing-complete.

[therube]

EDIT: I guess what I'm saying is that if file:// is allowed, you crash - even with XSLT protection enabled.

(And then maybe I'm not understanding what is supposed to happen, & if you allow file:// <or some malware domain?> then that is to be expected?)

[ i was typing as you were replying, & from the looks of it we are saying the same thing in different ways ]

[therube]

For those wishing to (try?) to crash their browser, another testcase can be found at URL: in this bug,
Bug 460090 - Firefox crashes (segfault) on attempting to view XSL Transform (xml file with linked xsl) [ txMozillaXSLTProcessor::TransformToDoc ]

* So with an unpatched Mozilla & without NoScript 1.9.1.5, you'll crash.
* With an unpatched Mozilla & NoScript 1.9.1.5 & XSLT enabled & launchpadlibrarian allowed, you'll crash.
* With an unpatched Mozilla & NoScript 1.9.1.5 & XSLT enabled & launchpadlibrarian blocked, no crash.
* (And with a patched Mozilla, no crash.)

[GµårÐïåñ]

It will work if the attacker's site is not allowed. In other words, I'm regarding XSLT just as it was scripting, since XSL has been demonstrated Turing-complete.

Understood.

For those wishing to (try?) to crash their browser, another testcase can be found at URL: in this bug,
Bug 460090 - Firefox crashes (segfault) on attempting to view XSL Transform (xml file with linked xsl) [ txMozillaXSLTProcessor::TransformToDoc ]

* So with an unpatched Mozilla & without NoScript 1.9.1.5, you'll crash.
* With an unpatched Mozilla & NoScript 1.9.1.5 & XSLT enabled & launchpadlibrarian allowed, you'll crash.
* With an unpatched Mozilla & NoScript 1.9.1.5 & XSLT enabled & launchpadlibrarian blocked, no crash.
* (And with a patched Mozilla, no crash.)

Checked there and the dev build is holding its ground. As long as not allowed, the crash is a no go. Thanks for the test case and thanks Giorgio.

[therube]

Here is the report (now visible, earlier it was not) of the bug which was actually implemented as the fix: Bug 485286 - XSLT should heap allocate all evalContexts.

[Riccardo]

Thanks for the feedback; I saw the browser crashing so I suspected I could be vulnerable but it was not the case.
As usual noScript rocks, thanks Giorgio