In 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:

  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 ( 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 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!” :)

12 Responses to “Firefox Light Speed Update and NoScript XSLT Protection”

  1. #1 » Lock Down Firefox for the Weekend says:

    […] XBL Returns from the Dead Firefox Light Speed Update and NoScript XSLT Protection 26 03 […]

  2. #2 GµårÐïåñ says:

    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.

  3. #3 Aerik says:

    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?

  4. #4 Giorgio says:

    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.

  5. #5 John Drinkwater says:

    BBC’s Click television programme (a weekly tech show) just had a 1 minute slot mentioning noscript, should get you some users ;)

  6. #6 Giorgio says:

    @John Drinkwater:
    Great news, thanks for sharing!
    Any way to watch it online?

  7. #7 Giorgio says:

    @John Drinkwater:
    don’t mind, I’ve found it, about at 20′:30” :)

  8. #8 » NoScript on BBC News! says:

    […] reader “John Drinkwater” just informed me that the BBC News’ “Click” TV programme aired yesterday (March 27th 2009) had one […]

  9. #9 Adrie=l says:

    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.



  10. #10 me says:

    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.

    and so on

    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.


  11. #11 Pseudonymous Coward says:

    I don’t think it’s a good idea for NoScript to add a Adblock Plus whitelist. It violates user privacy and control to some extent. Would appreciate if you would remove it. Thanks.

  12. #12 djh says:

    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?

Bad Behavior has blocked 2714 access attempts in the last 7 days.