Well, some people have recently asked why I am on some NoScript release notes.. and that's a good question..
I haven't released any details on the hacks against NoScript, since most of them where reported privately to Giorgio..
This is not the exception, I wont release any 0days here, I'll just give the details of the issues that I've reported in the past, and current NoScript users are immune to.
Is important to say, that Giorgio fixes stuff in "hours", (or minutes in some cases), and he has done some crazy stuff, just so NoScript users can be safe, so if you dont use it, go get it.
So, I'll go on chronological order:
+ Fix for Sirdarckcat's JS redirection trick
That was.. if a website has an open redirection (like, for example, Google's default open redirection feature), and you have that website as trusted (such as most people I guess they have.. Google).. a embed script on a website, pointing to Google's redirection, will be reported to be "from Google", and it will be loaded and executed.
This was useful for example, to attackers that were not able to make a self contained XSS payload, and they needed to load the script from their website, but since their website was surely not on their victims whitelist, then the attack would be unsuccesfull.
Anyway, by means of this, an attacker could be able to do something like the following PoC: http://www.sirdarckcat.net/hades
There I use another redirection on pages.google.com.
If you use NoScript>=126.96.36.199, this attack will be unsuccesful.
v 188.8.131.52That was an issue on NoScript XSS payload detection, that I discussed some time ago.
+ srv.br "special" TLD (thanks Rodrigo Ristow Branco)
+ Better protection against "setter" based XSS vectors and encoded
"name" payloads (thanks RSnake, Sirdarckcat and Kuza55, see
+ Improved hidden links management, preserves original body CSS
attributes when possible (thanks mdots)
The issue was that NoScript didn't detected setter/getter assignations, and so http://ha.ckers.org/xss.swf?a=1:setter/**/a=eval,setter/**/b=atob,a=b=name
Was able to bypass NoScript filters.
The xss.swf page was removed by RSnake, and (if you have ha.ckers.org as trusted) you will see NoScript XSS detection alert, if you are using NoScript >=184.108.40.206
Well, I didnt reported that, I just inspired ma1 (and I dont know the details), but.. I guess that means that now -moz-binding XBL are not loaded if they are hosted on an untrusted website.
+ JAR uris are forbidden from loading as documents by default, see
http://noscript.net/faq#jar for details
+ Block untrusted XBL (thanks Sirdarckcat for inspiration)
x Various IFrame blocking refinements
This is probably related to rsnake's hacking attempt.
x Changed noscript.filterXGetRx default to make single quote removal
happen only after positive injection checks (thanks sirdarckcat for
About that one, it was a bug (not a vulnerability), that removed single quotes from websites, and iframes on some situations.
Actually I discovered this while visiting kuza55's blog, since the little iframe in the top of blogspot blogs include the blog's title, and his blog title has a single quote.. that created some errors.
x Fixed Injection Checker checking ASCII 43 as a "plus" sign but not
as a www-form-encoded space (thanks Sirdarckcat for report)
x Google search anti-XSS exception now checks for real TLDs, rather
than short 2nd level domains (thanks Sirdarckcat for report)
+ Refactored unescaping flow, allowing for easier extension
+ Ebay-style unescaping
That's detailed on sla.ckers, here:
I'll quote my message:
Re: Hacking noscriptPosted by: sirdarckcat (IP Logged)Date: June 16, 2008 04:02AM
Ah! hacking noscript?
for example.. (eBay has a XSS issue very similar to the one I'm describing (well, actually, a lot of sites, but eBay rocks))
But duuuude!! what's happening?
Well, NoScript thinks, that.. "+" is a plus.. but in reality.. "+" is a space, and so..
var x=''+alert(document.cookie) //a:';
is valid js code! (damn, I'm good, 10 minutes to hack NoScript :D)
PS. It's a joke, noscript is great :P, and even do I did spent 10 minutes to find the issue, it was because I had this idea for attacking noscript since a couple of months ago, but I didnt tested it till today.
Let's take a look at NoScript's default anti-xss rules:
That means, well.. that:
Will bypass NoScript (because we all trust google =D), but.. wait.. that's for google domains exclusively right?
Well, wrong!! because, well.. 20 bux, we can get a 3 letter domain [www.3character.com]
And so do:
Pointing google.xss.com to your router or something.
Anyway, hacking noscript is fun :D
And in any case someone wondered..
And yeah, that's not triggering noscript alarms :D
And after all, this is ma1 response (where he uncovered that eBay uses a weird Q encoding, I didn't saw):
Re: Hacking noscriptPosted by: ma1 (IP Logged)Date: June 16, 2008 09:36AM
Now that it's fixed, I'll explain my innuendo to Ebay's "scary and brainless" issue, which reminds me closely last month's Base64 Yahoo one.
Your PoC was
and it did not bypass NoScript. I guess you meant to write it in the "mixed plus" form, but this is not.
But here's the truly scary one:
As you can see, ebay uses its own custom "Q-encoding", allowing XSS payloads virtually undetectable to any filter, except NoScript >= 220.127.116.11 ;)
IMPORTANT REQUEST (rules change)
Since as far as I can see NoScript now is actively used by more than 1.5 million users, it would be kind of you if new issues were responsibly disclosed to me before posting them there.
I guarantee to handle them the very same day I read your report and to publish a development build with proper credits, but since one week is probably the minimum user-bearable window for automatic updates on stable releases, a 7 days grace period would be nice as a compromise to avoid an excessively tight update schedule for stable version users.
x Restored the noscript.forbidData preference to its orginal "true"
default value (thanks Sirdarckcat for reporting an issue in the
about:blank context prevented by this change)
This are the e-mails:
/(?:Ctrl|Shift)[::click::]/.test(NoScript);So, that's all, we are on 1.7.1 and this last bug was fixed on 18.104.22.168, so we are all safe =)
Eduardo Vela <> Sat, Jun 21, 2008 at 7:07 AM To: Giorgio Maone <>
I've mounted a PoC:
Hold Control and then click somewhere.
The script runs on about:blank context.. so it's not so, so, dangerous, but anyway..
Arnold Schwarzenegger - "I have a love interest in every one of my films - a gun."
Giorgio Maone <> Sat, Jun 21, 2008 at 9:32 AM To: Eduardo Vela <>
Thanks for the info, it's very interesting.
I'm investigating it.
Giorgio[Quoted text hidden]
Giorgio Maone <> Sat, Jun 21, 2008 at 9:35 AM To: Eduardo Vela <>
BTW, shift does not work for me (must still test on a clean profile, though) but ctrl does.[Quoted text hidden]
Eduardo Vela <> Sat, Jun 21, 2008 at 9:36 AM To: Giorgio Maone <>
Control should open the script on a new tab, and shift on a new window.. maybe popup blocker stuff, or something?[Quoted text hidden]--
Frank Lloyd Wright - "TV is chewing gum for the eyes."
Giorgio Maone <> Sat, Jun 21, 2008 at 9:38 AM To: Eduardo Vela <>
Maybe, or Tab Mix Plus.
Shift does open a window for me, but it's empty and no script gets executed.[Quoted text hidden]
Giorgio Maone <> Sat, Jun 21, 2008 at 9:56 AM To: Eduardo Vela <>
Hence expect a fix build in a very short time.
Thanks![Quoted text hidden]
Giorgio Maone <> Sat, Jun 21, 2008 at 10:12 AM To: Eduardo Vela <>
OK, I found the culprit.
At a certain point in time I turned the default for the "noscript.forbidData" about:config preference to "false", in order to work-around a Firebug bug. It seemed a relatively innocuous change, considered also that about:blank is not in the default whitelist.
Anyway, since the Firebug issue is obsolete and I'm much more worried of this kind of bypass, next build will restore the original "true" default.
Giorgio[Quoted text hidden]
Giorgio Maone Sat, Jun 21, 2008 at 10:34 AM To: Eduardo Vela
Please wait for public release of 1.7 (in a week or even earlier) to disclose the details.[Quoted text hidden]