Yes, you're right on the fact a targeted attack might inject on-site content which might be allowed by your whitelist, but this is an unlikely scenario, especially in mass attacks like these, because for the attacker is much more practical injecting a small, stealthy inclusion and host the real payload elsewhere, on a server in his full control where he can log the activity and/or mutate the code as needed.
Furthermore, you can configure NoScript to execute plugin content (e.g. Flash) on demand (after clicking on a placeholder) on whitelisted sites as well, hugely reducing the attack surface even on trusted pages.
Experimental "Force Secure Cookies" feature, mitigates HTTPS cookie
hijacking attacks (http://tinyurl.com/cookiehijack).
Enabled by
default, it can be disabled either globally, by toggling the
noscript.secureCookies about:config preference, or for specific
domains only, by listing them (space or comma separated) in the
noscript.secureCookiesException about:config preference
Whenever a cookie is set over a secured HTTPS connection, NoScript forcibly flags it as "Secure" even if the server didn't. Therefore the browser won't leak it anymore over insecure connections.
Obviously this feature works always as long as it's turned on, independently from JavaScript/Java/Flash/Plugins permissions.
You can easily create a custom download manager definition which handles an "emulated" cookies.txt file to your script.
Notice that the legacy cookie.txt did not contain session cookies, while the FlashGot-produced one does.
If either the attacker site containing the applet tag (likely) or Facebook (unlikely) are not whitelisted, the applet won't run by default.
Furthermore, if NoScript is configured as a content blocker as kaidadragonfly said, there's no chance for the applet to run even if both sites are whitelisted.
The tag cannot be embedded in a facebook page, it must be embedded in a 3rd party site, even if it pointing to the GIF hosted on the facebook domain. Under these conditions, NoScript still blocks it.
As I commented here, SSL and SSP are orthogonal technologies whose correct and joint adoption should be required for any website performing sensitive transactions: the former ensuring integrity and, to a certain extent, identity; the latter defining and guarding application boundaries.
Those websites should encourage their users to adopt a SSP complaint browser, and complaint browsers should educate users to prefer SSP complaint sites with visual clues, just like we're already doing with EV-SSL (and for better reasons in this case, maybe).
On my side, I'm considering to highlight valid SSL + restrictive SSP websites as more reliable candidates for NoScript whitelisting.
Just check NoScript Options|Plugins|Apply these restrictions to trusted sites too.
In this configuration, NoScript effectively replaces FlashBlock, and it works on plugins different from Flash as well.
SWF and other payload files cannot be uploaded and hosted on the compromised web server as easily as SQL-injecting a script fragment which downloads them from a 3rd party site in full control of the attacker.
In this and all the recent mass-infection cases, the 3rd party hosts have been improbable domains Chinese domains likely registered ad hoc (such as wuqing17173.cn, woai117.cn or dota11.cn), and very unlikely to be in your NoScript whitelist, no matter how savage your browsing habits could be.
So in all "real world" scenarios seen so far, this one included, you are protected by NoScript in its default configuration, which blocks 3rd party embeddings even if you're visiting a trusted page.
Then if you want extra protection for the use cases you've listed (i.e. frequent usage of Flash-intensive community driven web sites),
you can also configure NoScript to block ALL the embedded objects, with no regard for their origin: you will still be able to temporarily allow them selectively, by clicking on a visual placeholder.
That's the difference between NoScript's script management and the ordinary enable/disable JavaScript controls.
NoScript lets you allow JavaScript on the sites you trust (and those only), either temporarily or permanently, with a click.
Furthermore, it gives you the same trust-based control over other potentially dangerous and exploitable technologies, like Java or Flash, and protects your trusted sites against XSS attacks.
No, adoblocking "firefoxrurl:" won't work because Firefox doesn't receive a firefoxurl:, but a javascript: URL (The "firefoxurl:" part is stripped out by IE or whatever the calling application is).
As I said, NoScript it the extension providing specific protection against this class of attacks.
Firefox users with the NoScript extension installed have been already protected both from MacManus/Larholm remote code execution and from Rios "Universal XSS" since June, the 22th, see NoScript changelog.
More in general, they're protected from chrome privilege escalation gained by opening non-chrome URLs in top-level chrome windows (Larholm's PoC) and from javascript: URLs being loaded in externally opened browser shells (Rios' PoC), no matter if attempted through the firefoxurl: handler (like in this specific case) or by other yet unknown means, thus these features are meant to stay in place even after Firefox 2.0.0.5 with its commandline-specific fix is released.
This URL obviously doesn't match the regular expression above, hence is subject to NoScript anti-XSS filters. At any rate, looks like Yahoo already fixed it (before the slashdotting, apparently).
Yes, disabling JavaScript on untrusted sites (or better said, enabling JavaScript only on trusted sites) protects from this.
All these exploits work only if JavaScript is enabled on the attacker's page.
Slashdot Mirror
Yes, you're right on the fact a targeted attack might inject on-site content which might be allowed by your whitelist, but this is an unlikely scenario, especially in mass attacks like these, because for the attacker is much more practical injecting a small, stealthy inclusion and host the real payload elsewhere, on a server in his full control where he can log the activity and/or mutate the code as needed. Furthermore, you can configure NoScript to execute plugin content (e.g. Flash) on demand (after clicking on a placeholder) on whitelisted sites as well, hugely reducing the attack surface even on trusted pages.
FlashBlock is handy, but not a security tool.
NoScript is likely to protect you anyway
Whenever a cookie is set over a secured HTTPS connection, NoScript forcibly flags it as "Secure" even if the server didn't. Therefore the browser won't leak it anymore over insecure connections.
Obviously this feature works always as long as it's turned on, independently from JavaScript/Java/Flash/Plugins permissions.
You can easily create a custom download manager definition which handles an "emulated" cookies.txt file to your script. Notice that the legacy cookie.txt did not contain session cookies, while the FlashGot-produced one does.
You can use FlashGot to integrate Firefox with wget (and many other download managers), including transparent cookie support.
You should not depend on FlashBlock for security, because it can be easily circumvented. And, as reported in other comments, FlashBlock does not even work reliably against this very PoC.
NoScript blocks both.
If either the attacker site containing the applet tag (likely) or Facebook (unlikely) are not whitelisted, the applet won't run by default.
Furthermore, if NoScript is configured as a content blocker as kaidadragonfly said, there's no chance for the applet to run even if both sites are whitelisted.
The tag cannot be embedded in a facebook page, it must be embedded in a 3rd party site, even if it pointing to the GIF hosted on the facebook domain. Under these conditions, NoScript still blocks it.
Even if Facebook is whitelisted, the applet wouldn't run because it's hosted on a different site.
NoScript checks both the embedding site and the embedded (Java) object against the whitelist to determine if it can be run.
As I commented here, SSL and SSP are orthogonal technologies whose correct and joint adoption should be required for any website performing sensitive transactions: the former ensuring integrity and, to a certain extent, identity; the latter defining and guarding application boundaries.
Those websites should encourage their users to adopt a SSP complaint browser, and complaint browsers should educate users to prefer SSP complaint sites with visual clues, just like we're already doing with EV-SSL (and for better reasons in this case, maybe).
On my side, I'm considering to highlight valid SSL + restrictive SSP websites as more reliable candidates for NoScript whitelisting.
Just check NoScript Options|Plugins|Apply these restrictions to trusted sites too. In this configuration, NoScript effectively replaces FlashBlock, and it works on plugins different from Flash as well.
SWF and other payload files cannot be uploaded and hosted on the compromised web server as easily as SQL-injecting a script fragment which downloads them from a 3rd party site in full control of the attacker. In this and all the recent mass-infection cases, the 3rd party hosts have been improbable domains Chinese domains likely registered ad hoc (such as wuqing17173.cn, woai117.cn or dota11.cn), and very unlikely to be in your NoScript whitelist, no matter how savage your browsing habits could be.
So in all "real world" scenarios seen so far, this one included, you are protected by NoScript in its default configuration, which blocks 3rd party embeddings even if you're visiting a trusted page.
Then if you want extra protection for the use cases you've listed (i.e. frequent usage of Flash-intensive community driven web sites), you can also configure NoScript to block ALL the embedded objects, with no regard for their origin: you will still be able to temporarily allow them selectively, by clicking on a visual placeholder.
It explains how the exploit works, how developers would/should avoid it and how users could protect themselves: http://hackademix.net/2007/09/26/gmail_csrf/
Reporters of valid critical security bugs will receive a $500 (US) cash reward and a Mozilla T-shirt
OK, maybe it's time to adjust the cash for the weak USD, but anyway...
That's the difference between NoScript's script management and the ordinary enable/disable JavaScript controls.
NoScript lets you allow JavaScript on the sites you trust (and those only), either temporarily or permanently, with a click.
Furthermore, it gives you the same trust-based control over other potentially dangerous and exploitable technologies, like Java or Flash, and protects your trusted sites against XSS attacks.
NoScript's specific countermeasures against this exploit are independent from JavaScript permissions.
They prevent specific kind of URLs from being opened from external applications and/or gaining chrome privileges.
Nevertheless, using NoScript but keeping "all javascript enabled" is not best idea I've ever heard of.
You're either using NoScript or an O.S. different of Windows.
No, adoblocking "firefoxrurl:" won't work because Firefox doesn't receive a firefoxurl:, but a javascript: URL (The "firefoxurl:" part is stripped out by IE or whatever the calling application is).
As I said, NoScript it the extension providing specific protection against this class of attacks.
Firefox users with the NoScript extension installed have been already protected both from MacManus/Larholm remote code execution and from Rios "Universal XSS" since June, the 22th, see NoScript changelog.
More in general, they're protected from chrome privilege escalation gained by opening non-chrome URLs in top-level chrome windows (Larholm's PoC) and from javascript: URLs being loaded in externally opened browser shells (Rios' PoC), no matter if attempted through the firefoxurl: handler (like in this specific case) or by other yet unknown means, thus these features are meant to stay in place even after Firefox 2.0.0.5 with its commandline-specific fix is released.
The Yahoo search exception is ^http://([a-z]*)\.?search\.yahoo\.com/search(?:\?| /\1\b) and does not match any known vulnerable URL.
2 2%3E%3Cimg%20src=14%20onerror=alert(String.fromCha rCode(88,83,83))%3E&y=Search&fr=yfp-t-501
The (formerly) vulnerable page is the advanced search configuration form:
http://search.yahoo.com/web/advanced?ei=UTF-8&p=%
This URL obviously doesn't match the regular expression above, hence is subject to NoScript anti-XSS filters.
At any rate, looks like Yahoo already fixed it (before the slashdotting, apparently).
-
Brendan Eich, the father of JavaScript, proposes a <JAIL> tag to block scripting (PDF slides warning)
-
RSnake's take on content restrictions proposals.
And for users? good ole NoScriptYou do realize he's talking about the NoScript Firefox Extension, right?
Yes, disabling JavaScript on untrusted sites (or better said, enabling JavaScript only on trusted sites) protects from this. All these exploits work only if JavaScript is enabled on the attacker's page.