The Chrome in the wild exploits inventory

Kees, I disagree here a bit as I think that your perception is too focused on "intrusion". I agree that Chrome probably protects very well against malware which could manipulate your system in one way or the other. However, there are 2 other aspects:

1. There are threats where the sandbox doesn't provide any protection. In particular, there is this wide-spread beast called XSS. Yes, I know that Chrome has the built-in XSS Auditor but the question is how reliable it works. When it was introduced in January 2010, Adam Barth wrote that they "were aware of a few ways to bypass the filter". And the renowned XSS expert Mario Heiderich wrote in his May, 2012 (2 years later!) thesis (p. 87):

Granted, some time has passed since then, and one should assume that further improvements have been added. Nevertheless, a couple of bypasses have been published in the meantime (two examples) which seem to be not yet fixed. Considering the large number of XSS variants, bypasses are not too surprising. A recent Blackhat presentation says:

Not very reassuring if you ask me, considering that only a small number of domains seem to have implemented CSP so far. So the only real protection (also against CSRF to some extent) is: disabling scripts. No scripts = no XSS. Period. I know, of course, that most sites require javascript in order to function properly. But blocking, at least, 3rd party scripts should protect against most XSS attacks.

2. The other aspect missing in your statement is privacy/fingerprinting. We all know that disabling javascript is important to stop trackers and many fingerprinting techniques. Further remarks are unnecessary as this has been discussed here very often.

However, some remarks specifically about µMatrix:
1. It comes with several huge hosts files with thousands and thousands of adservers/trackers/malware sites. We all know that hosts files are not perfect: They cannot completely cover the whole dark internet, and they contain false positives at times. Nevertheless, I think that they provide a good protection against many of those evil guys out there. Every µMatrix user will probably think twice or even thrice before he/she accidentally whitelists a site which is explicitly blacklisted. A big advantage, IMHO. This mitigates also many XSS risks, of course.
2. The other big advantage is the existence of scopes in µMatrix. Every user who isn't out of his/her senses doesn't use the global scope but rather the domain-specific scope (or even the site-specific scope) in order to manage permissions for a specific domain/site. If you whitelist something in a domain-specific scope, the respective rules are "sandboxed" as they are not applied anywhere else. A 3rd-party domain whitelisted in a domain-specific-scope for example1.com is still blocked (graylisted = pale red or even blacklisted = dark red) for example2.com etc. This also mitigates risks considerably if a malicious site is accidentally whitelisted.

 

Very good point, I can't agree more!
uMatrix protects you from not only XSS, but as it includes XHR protection it can protect CSRF & DNS rebinding (depends on setting), as well as most of clickjacking. Considering potential damage by XSS and the fact it is one of the most common bug among websites, I never understand why some people here (security caring guys) only care about malware day after day, deploying paranoid layered protection for it, while no or little protection against other threats such as XSS and non-malware MITM. It's as if you put many locks to front door while back door and windows are open or no lock.
As you said, scope feature mitigates risk of whitelisting and vastly reduces chance of XSS abusing whitelist. If it was Noscript, you needed to never permanently allow scripts for login site.

 

thanks Yuki and tlu for your feedback. I knew there was a good reason not to let go of uMatrix

 

Please let's discuss script blockers in this thread https://www.wilderssecurity.com/threads/food-for-thought-safe-browsing-and-blocking-scripts.373285/

 

OMG XSS

 

At least the most common XSS attacks are the reflected (non-persistent) types, which are usually triggered when a victim is tricked into clicking a malicious javascript link in a phishing email, for example. The persistent XSS types stored on a website or web application are far more of a concern but also far less common.

 

XSS is not something that is an issue specifically related to Google Chrome. The lack of any Chrome exploits being used ITW means that this topic is going towards subjects which are somewhat irrelevant.

 

I apologize if I had gone off-topic in this thread with the replies regarding Sandboxie. I thought it was pretty much relevant to the topic because most exploits are neutered thanks to the sandbox and the use of memory mitigation techniques. Kees himself emphasizes his condition that a browser needs a sandbox if to be discussed here when another member mentioned Firefox.

I had to reply to CWS because there's a fundamental misunderstanding of the sandbox concept.

Since the thread is about in-the-wild exploits for Chrome, I think the reason it is difficult to find one is because Chrome sandbox is pretty strong as is and that quick updates reduces the chances of a successful sandbox escape in the wild. The average user simply does not really need to worry.

If we were to simply focus on the concept of a sandbox itself...

A sandbox is basically a set of restrictions in which a program is only able to access certain resources as defined by the policy. A sandbox, unlike how some perceive it to be, is nowhere a complete isolation (despite some sandboxes implementing redirection or 'virtualization') because apps still need to interact with the system resources or another app to function as desired.

There will always be ways to break out of a sandbox because of these required interactions and underlying OS bugs but that does not mean having double of it is better.

It is just that a native sandbox (like the one implemented in Chrome) is preferential because

a) the restrictions defined are simply OS-provided mechanisms without any additional fancy code
b) the broker does not require high privileges
c) the program/app can be designed from the ground up with the restrictions in mind
d) the sandbox is optimized for one program, therefore requires minimal concessions/allowances

whereas a 3rd-party implementation of a sandbox is the opposite:

a) it is additional code which adds complexity; and it injects it's code to the sand-boxed processes
b) the broker requires high privileges in order to supervise and restrict apps
c) programs/apps are not designed with a 3rd-party sandbox in mind. While the 3rd-party sandbox can restrict the apps, it cannot alter the design of the programs
d) the sandbox is not optimized for one program alone. It does not know which exact resources are needed beforehand and it needs to keep up with programs to ensure they don't break when sand-boxed.

If I were to put it bluntly, I have high doubts an in-the-wild exploit that escape Chrome's sandbox (an impressive feat) would be contained by Sandboxie (or any other 3rd-party sandbox if avail); given that Chrome's sandbox already does not allow much access on a per-process, per-tab basis.

Also take note of this:

http://www.chromium.org/developers/design-documents/sandbox

Regarding XSS, I think the XSS Auditor in Chrome is limited because it needs to cater to the majority. Disabling Javascript would bolster the level of protection against XSS but that requires more hands-on/interaction than most users would feel comfortable with.

 

Too bad you couldn't explain this earlier, Safeguy and big thanks for your time and patience for such detailed explanations, Safeguy, just for the record, by a 3rd-party implementation of a sandbox you mean sandboxes like Sandboxie and Bufferzone, right?
You wouldn't mind if I ask you any other additional question regarding types of sandboxes through private messages (right now, I have zero questions at this moment)?