Are sandboxes overrated?

Question

I've stumbled upon the following on the blog of the NoScript developer Giorgio Maone.

First, he quotes the following ArsTechnica article about an XSS bug in Adobe Flash:

As useful as sandboxes are in restricting potentially buggy code to a small part of the operating system, they do nothing to minimize the damage that can be done by attacks that exploit universal XSS flaws, researchers said.

He then points out the following interesting statement:

I was already preaching this four years ago: the more our assets move “in the cloud”, the less traditional security measures, meant to protecting just your local system, suffice.

The battlefield is the web now, and there’s no coming back…

Question

Is this true? Should browser security focus more on exploits which take place "in the web" only?

By "in the web" I mean exploits which do not try to install malware on the user's computer, but try to steal data or abuse via XSS or clickjacking for example.

It's a fact that I do so much on the web now. My email account has grown to the importance of the digital wallet. Most of my internet accounts and other sensitive information are passed via the internet.

Chrome's PR successfully advertises Chrome as a very secure browser. Which is probably true when talking about protecting your computer from malware. But protecting my online activity is just as important.

Answer 1

No. Sandboxes aren't overrated. They've very useful. They are not a silver bullet -- they don't solve every security problem -- but they do have substantial value.

Really, don't think this is especially new. If you read the original paper describing the Chrome security architecture, it clearly explains why sandboxing is valuable while also elucidating its limitations. For instance, the introduction says:

Chromium's architecture is designed to mitigate the most severe vulnerabilities, namely those vulnerabilities that let an attacker execute arbitrary code. [...] We find that 38 of the 87 rendering engine vulnerabilities allowed an attacker to execute arbitrary code and would have been mitigated by Chromium's architecture. These account for 70.4% (38 of 54) of all disclosed vulnerabilities that allow arbitrary code execution.

So Chrome's architecture makes a huge contribution to mitigating the most severe vulnerabilities that one can have in a browser.

At the same time, the Chrome team never claimed that sandboxing is a silver bullet. For instance, see "Out-of-Scope Goals" in that paper for a lucid description of some vulnerabilities that Chrome's sandboxing architecture does not attempt to mitigate. Anyone who has been following this should already be aware of the fact that sandboxing does not claim to stop all security problems.

Read the paper here:

• The Security Architecture of the Chromium Browser, Adam Barth, Collin Jackson, Charles Reis, and The Google Chrome Team.

Please remember, vulnerabilities that let an attacker run malicious code on your local system (also known as drive-by downloads) are the most severe kind of vulnerability. An attacker who exploits such a vulnerability can also attack all of your data "in the cloud" or on servers. The reverse is not true. Consequently, drive-by downloads are the most severe kind of vulnerability to have in a web browser.

If you look a few years back, these "drive-by-download" vulnerabilities in browsers were very common. Given their severity and prevalence, it is only natural that researchers and security professionals spent a lot of energy looking for ways to mitigate or eliminate those kinds of vulnerabilities. The security community has found reasonable ways to significantly reduce the prevalence of such vulnerabilities.

So, sure, once you make good progress on eliminating the most common, most severe vulnerabilities, it is only natural to next start looking at how to address the next-most-serious problems. But that doesn't mean sandboxing is "overrated". And, it doesn't mean that the energy put into defeating drive-by downloads was wasted or misplaced. It wasn't. It was important, and remains important today.

Answer 2

This is an interesting thought question. We are talking about attacking the browser versus attacking the application and what is going on inside of the application.

Both will still continue to be important. The real difference from the end-user perspective is that you can choose which browser to use, which web apps/vendors to browse to - you are in control. On the web app side, this is really the developer's problem.

In reading the original blog post, it doesn't seem to me that he is implying that browser's should have some type of real time debugging to detect XSS and CSRF. I think he is just making a common point that most developers don't care about security. While you can use XSS and CSRF to attack an existing Flash attack, what comes to mind to me from his quote is someone who puts up a malware site and gets you to go there - sandboxing could help some malicious code from escaping to the operating system. Whereas an XSS attack is typically against a legitimate site and application that the attacker does not directly control.

Another possibility is that the author has recently saw some AV company talk about how their sandbox will protect you from Internet threats (I have seen that as a feature in some recent AV suites, a sandboxed browser for untrusted sites) and was angry about the focus again being on the end-user. From the end-user perspective you can only stop XSS from hitting you in a limited set of cases, for example you get a link which obviously has a script set in a GET parameter and choose not to click it or disable JavaScript and Cookies, etc; CSRF could still be in play.