Thank you for your commentary, which is quite to the point except for two details which I'd like to set straight:
The existence of this vulnerability, let alone its nature, has never been disclosed neither to me or the Tor Browser team. The very first hint I had about it has been this tweet by the ZDNet reporter, sent about one later than Zerodium's one, and noticed even later.
Based exclusively on that Zerodium's tweet (not a proper bug report, just a innuendo without even a link to a live PoC), the "NoScript team" (just me, actually) scrambled to create a reproducible test-case, dig in NoScript 5 "Classic"'s code base which had not been touched for months*, find the bug, fix it, test the patch, package two new versions (one for the beta autoupdate channel, one for the stable one) and deploy them both in quite less than one hour, real-time while been interviewed by the journalist. In the old days, when I had my own garage bands, our typical rehearsals were much longer -- and pleasant;)
* NoScript 10 "Quantum" has been the main branch and the only I focused on since December 2017: it's a complete rewrite and was born unaffected by this bug. NoScript 5 has been kept around so far for the Tor Browser and the others based on Firefox ESR 52, like Palemoon.
I'd like also to add that NoScript 10's code is much simpler, leaner and easier to understand / maintain, and has got a lot more "friendly" eyeballs reviewing it for possible flaws. Therefore I'm quite confident something like this wouldn't go unnoticed that easily. Anyway, I vow to keep fixing whatever security bug is found (either cooperatively or in a hostile and disturbing way, like in this case) as fast as humanly possible, and even a bit faster, like I always did:)
Some hints at what's happening with NoScript, with my proposal to preserve the edge Firefox has over Chrome in terms of innovation through extensions, despite the limitations of a Chrome-compatible API: https://hackademix.net/2015/08...
Easiest, one-click way to remove vulnerable SSL3 support from Firefox, while still allowing Mozilla to automatically enforce even safer defaults in future updates:
Painful, yes, but it should take care of this kind of attacks, as long as you can trust HTTPS (e.g. with Convergence).
Furthermore, NoScript 2.6.8.37rc2 introduce an experimental "Allow HTTPS scripts globally on HTTPS documents" mode (in Advanced>HTTPS>Permissions) if you value convenience over finer grained security.
Are there still security issues with having JS enabled?
Fresh from the summary of the upcoming BlackHat talk by Jeremiah Grossman, A Million Browser Botnet:
With a few lines of HTML5 and javascript code we’ll demonstrate just how you can easily commandeer browsers to perform DDoS attacks, participate in email spam campaigns, crack hashes and even help brute-force passwords. [...] no zero-days or malware is required. Oh, and there is no patch. The Web is supposed to work this way.
There is ZERO chance I'm going to use a browser which doesn't allow me to default JS to being disabled. NoScript is also FAR advanced beyond other similar tools, so it would REALLY SUCK to have to use Chromium's lame equivalent, but I will if it is the only choice. At least in other respects Chromium is pretty good.
In what ways is NoScript more advanced than ScriptSafe?
And yes, they're aware of the prerendering Chrome stats inflation problem, even though they believe it doesn't significantly skew their stats, for some reason they're unable to explain themselves (sounds like "faith" or "we're too lazy to adjust our data even though we could").
Disclaimer: the original (and only) NoScript can be detected as well, but at least you couldn't be notified by a JavaScript alert() box on a page where JavaScript isn't supposed to run;)
He will find all your installed extensions among the ones he's looking for, because every Chrome extension have a manifest.json file. This means that he just needs to crawl https://chrome.google.com/webstore/category/extensions for GUIDs of all the installable extensions, and he can detect your full extensions list.
There's no such a generic detection method for Firefox extensions. You can detect some (e.g. adblockers) by testing for their specific behavior and effects on web pages (e.g. how some DOM elements have been removed/hidden/inserted), but you can't develop a catch-all detection script, because Firefox extensions are generally undetectable.
sites which won't display their content until I allow Noscript to run all scripts on the page (including advertisers'), turn off Adblock, and disable Ghostery
If they can remember what password they used and where else they might have used it...
If you use Firefox's password manager you can ask it (Tools|Options|Security|Saved Passwords|Show passwords) and even search among its entries, by site, username or password.
Otherwise I'm afraid you will need to change them all:(
http://blog.mozilla.com/security/2010/12/27/addons-mozilla-org-disclosure/
Active accounts have their password SHA-512 hashed with per-user salt, so they're safe (for a while).
However those 44,000 holders of older (and now disabled) MD5 hashed accounts should rush changing their passwords elsewhere, if they have the bad habit of using the same password everywhere...
As you probably know, Roman Catholic "doctrine" doesn't come directly from scriptures, but it's mediated by tradition and Magisterium, i.e. dogmas are essentially whatever the Pope decides must believe.
Of course controversial scriptural sources are cited to support this dogma, but like anything theological or mariological (!), they're essentially mental masturbation.
http://en.wikipedia.org/wiki/Immaculate_Conception Unfortunately most "believers" don't know much about their doctrine nor about their bible. Otherwise, atheists would be the vast majority and the world would be a better place.
You're wrong, NoScript DOES give protection against this attack.
The malicious code comes from the mikeyylolz.uuuq.com, which is not in your NoScript whitelist even if you're using twitter.com with scripts allowed.
Slashdot Mirror
The NoScript dev -- not "devs" ;) -- here.
Thank you for your commentary, which is quite to the point except for two details which I'd like to set straight:
* NoScript 10 "Quantum" has been the main branch and the only I focused on since December 2017: it's a complete rewrite and was born unaffected by this bug. NoScript 5 has been kept around so far for the Tor Browser and the others based on Firefox ESR 52, like Palemoon.
I'd like also to add that NoScript 10's code is much simpler, leaner and easier to understand / maintain, and has got a lot more "friendly" eyeballs reviewing it for possible flaws. Therefore I'm quite confident something like this wouldn't go unnoticed that easily. Anyway, I vow to keep fixing whatever security bug is found (either cooperatively or in a hostile and disturbing way, like in this case) as fast as humanly possible, and even a bit faster, like I always did :)
Great work by Mozilla and the Tor Project on the lighting fast (
And yes, NoScript did protect against this (the Tor Browser has it built-in, for users who know what they're doing).
Some hints at what's happening with NoScript, with my proposal to preserve the edge Firefox has over Chrome in terms of innovation through extensions, despite the limitations of a Chrome-compatible API: https://hackademix.net/2015/08...
Easiest, one-click way to remove vulnerable SSL3 support from Firefox, while still allowing Mozilla to automatically enforce even safer defaults in future updates:
the SSL Version Control add-on.
NoScript Options>Advanced>HTTPS> Forbid Active Content unless it comes from a secure (HTTPS) connection .
Painful, yes, but it should take care of this kind of attacks, as long as you can trust HTTPS (e.g. with Convergence).
Furthermore, NoScript 2.6.8.37rc2 introduce an experimental "Allow HTTPS scripts globally on HTTPS documents" mode (in Advanced>HTTPS>Permissions) if you value convenience over finer grained security.
Netscape Composer, A.D. 1997.
Are there still security issues with having JS enabled?
Fresh from the summary of the upcoming BlackHat talk by Jeremiah Grossman, A Million Browser Botnet:
With a few lines of HTML5 and javascript code we’ll demonstrate just how you can easily commandeer browsers to perform DDoS attacks, participate in email spam campaigns, crack hashes and even help brute-force passwords. [...] no zero-days or malware is required. Oh, and there is no patch. The Web is supposed to work this way.
There is ZERO chance I'm going to use a browser which doesn't allow me to default JS to being disabled. NoScript is also FAR advanced beyond other similar tools, so it would REALLY SUCK to have to use Chromium's lame equivalent, but I will if it is the only choice. At least in other respects Chromium is pretty good.
In what ways is NoScript more advanced than ScriptSafe?
Besides some "minor" features first introduced by NoScript, which advanced the state of the art of browser security (such as the most effective in-browser XSS filter, the ClearClick anti-Clickjacking technology and the Application Boundaries Enforcer module), NoScript holds a modest advantage over all its Chrome-based "clones": basic script blocking which actually works ;)
The dark side of the new pope (Google translation of Google cache, original 2006 italian report is being DOSed).
... and NoScript.
The patch is not exactly a one-liner, because the implemented behavior is not as straight-forward as just "block 3rd party cookies".
It's "block cross-site cookies from origins which I've not visited yet as a 1st party websites and have already 1st party cookies from".
This means, for instance, that Facebook, Google and Twitter gets likely a free-pass to track almost anybody.
And that once you (accidentally or not) click any ad box, you give a free-pass to its advertising agency too.
I doubt they measure number of pages when measuring market share here.
Wrong, that's exactly what they do: Why do you base your stats on page views rather than unique visitors?
And yes, they're aware of the prerendering Chrome stats inflation problem, even though they believe it doesn't significantly skew their stats, for some reason they're unable to explain themselves (sounds like "faith" or "we're too lazy to adjust our data even though we could").
Does StatCounter take in account Chrome's page views inflation caused by its Instant Pages prerendering feature?
I'd be surprised, since even Google Analytics itself is affected...
Anyway, please be careful before announcing "Chrome usage surpassed this or that" :P
You might be interested in this: http://noscript.net/misc/scriptno-detector/
Disclaimer: the original (and only) NoScript can be detected as well, but at least you couldn't be notified by a JavaScript alert() box on a page where JavaScript isn't supposed to run ;)
Is he the same "Jedi Master" who allowed is lightsaber to be stolen??
Surrogate Scripts are meant to deal with this kind of crap.
Could you please show me some URLs to check?
If you use Firefox's password manager you can ask it (Tools|Options|Security|Saved Passwords|Show passwords) and even search among its entries, by site, username or password.
Otherwise I'm afraid you will need to change them all :(
http://blog.mozilla.com/security/2010/12/27/addons-mozilla-org-disclosure/
Active accounts have their password SHA-512 hashed with per-user salt, so they're safe (for a while). However those 44,000 holders of older (and now disabled) MD5 hashed accounts should rush changing their passwords elsewhere, if they have the bad habit of using the same password everywhere...
As you probably know, Roman Catholic "doctrine" doesn't come directly from scriptures, but it's mediated by tradition and Magisterium, i.e. dogmas are essentially whatever the Pope decides must believe.
Of course controversial scriptural sources are cited to support this dogma, but like anything theological or mariological (!), they're essentially mental masturbation.
http://en.wikipedia.org/wiki/Immaculate_Conception
Unfortunately most "believers" don't know much about their doctrine nor about their bible.
Otherwise, atheists would be the vast majority and the world would be a better place.
We can do it by snail mail only, but we've got an unofficial online counter: http://sbattezzati.it/
You're wrong, NoScript DOES give protection against this attack. The malicious code comes from the mikeyylolz.uuuq.com, which is not in your NoScript whitelist even if you're using twitter.com with scripts allowed.
Please check http://hackademix.net/2009/04/13/mikeyys-stalkdaily-twitter-worm-vs-noscript/
http://hackademix.net/2009/02/19/more-https-troubles/