Drive-by exploits

[moontan]

are there any other browser vulnerabilities beside javascripts, Flash and Java?

seems to me that since the browser is the most vulnerable it should be the first line of defense against nasties.

thoughts?

[Scoobs72]

Yeah, loads. Take a look at this old list of vulnerabilities for Firefox 3 as an example:

http://www.mozilla.org/security/know...firefox30.html

[moontan]

right...

which means NoScript does not protect against all of this.

tnx m8.

food for thoughts.

[moontan]

i think i'll switch to Chrome and ScriptNo.

i don't like ScriptNo as much as NoScript but Chrome has a sandbox.
can't wait for Firefox to have a sandbox.

[TonyW]

Originally Posted by moontan

which means NoScript does not protect against all of this.

Not only that, but if you whitelist a site in NoScript as one you trust to allow scripts to run and it gets compromised, then NoScript is no help then either...

[Cudni]

Originally Posted by TonyW

Not only that, but if you whitelist a site in NoScript as one you trust to allow scripts to run and it gets compromised, then NoScript is no help then either...

from
http://noscript.net/faq#qa1_11
* You may ask, what if site I really trust gets compromised? Will I get infected as well because I've got it in my whitelist, ending to sue as you said?
No, you won't, most probably. When a respectable site gets compromised, 99.9% of the times malicious scripts are still hosted on a different domain which is likely not in your whitelist, and gets just included by the pages you trust. Since NoScript blocks 3rd party scripts which have not been explicitly whitelisted themselves, you're still safe, with the additional benefit of an early warning
*

and controlling javascript is simply another layer of protection so for 0.01% when noscript doesn't help with malicious script, other layers; AV, OS should and do help.

[TonyW]

Originally Posted by Cudni

controlling javascript is simply another layer of protection so for 0.01% when noscript doesn't help with malicious script, other layers; AV, OS should and do help.

It goes without saying that various protection layers, including the ones you mentioned, go a long way to keep one safe.

[TheWindBringeth]

Originally Posted by Cudni

from
http://noscript.net/faq#qa1_11
* You may ask, what if site I really trust gets compromised? Will I get infected as well because I've got it in my whitelist, ending to sue as you said?
No, you won't, most probably. When a respectable site gets compromised, 99.9% of the times malicious scripts are still hosted on a different domain which is likely not in your whitelist, and gets just included by the pages you trust. Since NoScript blocks 3rd party scripts which have not been explicitly whitelisted themselves, you're still safe, with the additional benefit of an early warning

What is the logic behind that "99.9% of the time malicious scripts are still hosted on a different domain"? If a hacker is able to modify what is served up to your browser when you visit this compromised site, why would they not serve up the malicious scripts from that same site?

[moontan]

Originally Posted by TheWindBringeth

What is the logic behind that "99.9% of the time malicious scripts are still hosted on a different domain"? If a hacker is able to modify what is served up to your browser when you visit this compromised site, why would they not serve up the malicious scripts from that same site?

because the bad stuff that comes from other sites is mostly embedded in advertisements, from what i can tell.

it's easier to hack an add that a specific web site.
and more productive as well because with that one infected add you can contaminate many websites.

[Baserk]

^^I'd assume that when Maone wrote; 'When a respectable site gets compromised, 99.9% of the times malicious scripts are still hosted on a different domain', he means an ad server was hacked and not the actual website itself. So when you only allow the main site and not all other domains offering non-essential garbage/ads, you're OK.
I could be wrong though and like with a recent case in NL where the most popular news site itself was hacked and readers were treated to a banking trojan, Noscript wouldn't offer any consolation.

edit; Note to self; write faster than moontan.

[moontan]

Baserk:

edit; Note to self; write faster than moontan.

hahaha!

[TheWindBringeth]

OK, I was thinking a straight-up direct compromise of the target site itself. I get the third-party context.

http://play.typeracer.com/

[trismegistos]

Originally Posted by moontan

right...

which means NoScript does not protect against all of this.

tnx m8.

food for thoughts.

If you look on those lists, many are XSS(Cross-Site Scripting) and javascript redirects.

Otherwise, it still can protect. Most of these exploits on the browser side would still rely on scripting to cause memory corruptions in order to run arbitrary codes...

For e.g. an exploit targeting this vulnerability http://www.mozilla.org/security/anno...sa2010-19.html or the Mozilla Foundation Security Advisory 2010-19 Dangling pointer vulnerability in nsPluginArray would still require scripting. And so their suggested workaround was to disable scripting.

... And so NoScript would definitely help. Exceptions would be fonts, parsing vulnerabilities like for e.g the various image parsing vulnerabilites like jpg or SVG exploits which all have been patched. WMF image and embedded fonts vulnerabilities are mostly Windows or system based. These exploits would be able to push the payload even if you globally disable scripting and uninstall plugins. And these type of non-script based exploits are mostly served from scripting redirections from other domains, thus, NoScript would still definitely help. Sandboxing, memory corruption protections(EMET) and AE/SRP/Applocker/HIPS all provide additional layers. 99% of the time,these payloads are executables and so are easily blocked.

To add to what trismegistos said, here's a snippet from the noscript faq page:

Q: What is XSS and why should I care?
A: XSS stands for Cross site scripting, a web application vulnerability which allows the attacker to inject malicious code from a certain site into a different site, and can be used by an attacker to "impersonate" a different user or to steal valuable information. This kind of vulnerability has clear implications for NoScript users, because if a whitelisted site is vulnerable to a XSS attack, the attacker can actually run JavaScript code injecting it into the vulnerable site and thus bypassing the whitelist. That's why NoScript features unique and very effective Anti-XSS protection functionality, which prevents untrusted sites from injecting JavaScript code into a trusted web page via reflective XSS and makes NoScript's whitelist bullet-proof.

I'm always dubious of any security feature that claims to be "bullet-proof," but I think the point here is that noscript doesn't just blindly trust even the whitelisted sites.

[tlu]

To add what BrandiCandi said, here's a snippet from the Noscript features site:

Furthermore, NoScript's sophisticated InjectionChecker engine checks also all the requests started from whitelisted origins for suspicious patterns landing on different trusted sites: if a potential XSS attack is detected, even if coming from a trusted source, Anti-XSS filters are promptly triggered.

That's very important, and I think that many people are not aware of it.

[tlu]

I forgot to mention another important aspect from the same link above:

This feature can be tweaked by changing the value of the noscript.injectionCheck about:config preference as follows:
0 - never check
1 - check cross-site requests from temporary allowed sites
2 - check every cross-site request (default)
3 - check every request

This means that by default only suspicious patterns coming from other sites (even if they are whitelisted) are checked. However, if you set that value to 3 even suspicious patterns from the same site are checked, which is, e.g., relevant for forums where a posting can contain such code.

[moontan]

tnx everybody for the inputs!