For the attack to succeed,
all the following conditions need to be met:
- A malicious script manages to run entirely
- An exploitable vulnerability exists, either in the browser or in a browser plugin
- The malicious script manages to leverage the vulnerability to actually execute arbitrary native malicious code
#1 is unlikely but not impossible.
Unlikely because malicious scripts served by a trusted sites as a consequence of a server takeover (such as the infamous
Mass SQL Injection Attack) are usually the 1st stage of a more complex and possibly morphing script hosted on an external site in full control of the attacker. This approach offers several vantages for the attacker, because it does not suffer of any code size limitations (SQL injections are usually limited by the size of the injected DB field) and allows easy logging and modifications of the 2nd stage code. On the other hand, NoScript users are safe because the 3rd party 2nd stage script won't run.
Not impossible, especially in a targeted (non massive) attack, because the attacker may have discovered a vulnerable blob field and might prefer its JavaScript to be self-contained, trading flexibility for reduced traceability.
#2 is more complex to analyze, but even more unlikely to happen with NoScript.
If the attacker wants his attack to be cross-browser, the easiest targets are browser plugins, e.g. Flash, Java or Acrobat, where we've got tons of vulnerabilities discovered every month and working in all the supported browsers.
Therefore, if you run NoScript you're reasonably safe even if stage #1 is passed, because the attacker cannot inject plugin content using SQL injection.
However, again, exceptions are possible in a targeted attack, by exploiting either a Firefox 0day or a more severe (and very unlikely) full server takeover allowing the attacker to upload plugin content. But even in the latter case, you're still protected by NoScript if you enabled
NoScript Options|Plugins|Apply these restrictions to trusted sites as well.
#3 is the most unlikely, almost impossible condition to be met.
Assuming that you're using a modern browser on a modern system providing memory protection (and specifically DEP, enabled by default in Firefox 3), placing arbitrary native code in memory to be launched by the vulnerability exploitation is quite difficult, and
requires to be done by a subsystem which bypasses the memory protection, i.e. plugins such as Java, Flash or Silverlight.
Therefore, unless the site is so much compromised to host both the full JavaScript code and the malicious plugin content needed to fill an unprotected memory region with the native part of the attack,
you're safe just by using NoScript in its default configuration. And even if the site is fully compromised, if you enabled
NoScript Options|Plugins|Apply these restrictions to trusted sites as well you're still safe as explained above.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)