Firefox Light Speed Update and NoScript XSLT Protection
Posted by: Giorgio in Advisories, Mozilla, Security, NoScriptIn a twisted reverse April fool, Mozilla decided to anticipate the release from April the 1st: it's today, folks.
As you may already know, it fixes:
- 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);
- 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!" :)
March 27th, 2009 at 10:57 pm
[...] XBL Returns from the Dead Firefox Light Speed Update and NoScript XSLT Protection 26 03 [...]
March 28th, 2009 at 12:37 am
Thank you, its awesome to hear. I already installed the dev build and its awesome, so far no problem and I have run multiple test scenarios and NS held its ground, thanks.
March 28th, 2009 at 4:54 am
Wladamir made adblock plus capable of blocking XBL and dtd's. I wonder if he can make it capable of blocking XLT? It seems plausible. To date, ABP has been able to block anything defined as "active content" that noscript can. So, they should be able to do that, right?
March 28th, 2009 at 10:35 am
@Aerik:
ABP can theoretically block any load attempt (it uses the same base content blocking mechanism as NoScript), but can be also circumvented, while a good 30% of NoScript code is meant to prevent any circumvention.
XSL documents are stylesheets used to transform other XML documents, usually for presentation purposes. ABP does already stylesheet blocking, so you can block XSLs if you want (with some effort to tell CSS from XSL, which I'm not sure how trivial is in ABP, unless it checks also for MIME type). But again, if you're doing it for security purposes you should look elsewhere, because a motivated attacker will pwn you anyway.
March 28th, 2009 at 5:57 pm
BBC’s Click television programme (a weekly tech show) just had a 1 minute slot mentioning noscript, should get you some users ;)
March 28th, 2009 at 6:05 pm
@John Drinkwater:
Great news, thanks for sharing!
Any way to watch it online?
March 28th, 2009 at 6:17 pm
@John Drinkwater:
don't mind, I've found it, about at 20':30'' :)
March 28th, 2009 at 7:36 pm
[...] reader “John Drinkwater” just informed me that the BBC News’ “Click” TV programme aired yesterday (March 27th 2009) had one [...]
April 1st, 2009 at 3:28 am
Hello there!
well i have a theoretical question. first of all, i really appreciate your plugin, it works great. my question regards the use of javascript:
at this time, should it be considered best practice to never include javascript authentification mechanisms (a.k.a. username and passwd)
for logins on web pages?! in other words, i notice visiting various sites across the web, that authenticating (authentifying?) mechanisms always seem to work, but there have been exceptions............
another scenario might be that sometime in the future, i might consider building a website/web server, but because of my sysadmin/networking background, i would never choose to use a bunch of interactive eye candy on sites, capabilities which can be provided by javascript or flash for example.
i have to confess i am not so informed of the inner workings of java or javascript, but i do understand the concepts of buffer overflows or similiar exploits that can be deployed via a running process's priveledges etc--in other words, i am looking at this from a infosec view.
Many thanks for your help and your tools. It's also a great learning resource for those not so skilled in the inner workings of web technologies.
regards,
Adriel
April 5th, 2009 at 11:48 pm
salut,
me uses noscript and got a website that depends on xslt. me uses xml that semanticaly makes up the content and xsl to render html from it. its an entirely practical approach to xml and i really like that the major browsers are able to render it this days - keeps the transform away from my server.
today me got surprised - the website wont work, hacked the apache content type until me found out noscript blocked the xsl
me understands the concerns not to run xsl on the client side, but leaving ffox in a state where it cannot present the xml is not a good idea eighter...
display the source, replace with a simplified xsl, but dont just prevent xsl from transforming. looks like plaintext, but worse.
example xml:
File: index.xml
this is text.
hopefully this opens a new view to the xsl issue.
for me it is enough to know to enable my site. maybe some applications break similar or worse as mine did - it would be easy to let the user know.
peace
--me
May 1st, 2009 at 5:35 am
I don't think it's a good idea for NoScript 1.9.2.4 to add a Adblock Plus whitelist. It violates user privacy and control to some extent. Would appreciate if you would remove it. Thanks.
May 18th, 2009 at 9:49 pm
similar to me above in this thread, I am xslt developer and would like a method to deploy client-side xslt transformations reliably and not be hacked. Can you tell me best methodology to permit XSLT transformation of XML in FF 2.0 and higher?