(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

July 17, 2018 Comments closed

What is Google Chrome’s Site Isolation?

in Hashing Out Cyber Security

Site Isolation is a new feature in Google Chrome for reducing Spectre attacks

Site Isolation is a major change to the architecture of Google’s Chrome browser. It limits each render process to documents from a single site, essentially isolating each tab from one another to prevent attacks like Spectre and Meltdown. Previously, as far back as Chrome 83 the feature had been optional, available only by changing a flag to enable the feature.

Now, in Chrome 67, the feature is on by default. That means security against a couple of nasty vulnerabilities, but it also means that Chrome – which already gobbles up a computer’s resources while it runs – will now use 10-13% more RAM.

So what does this all mean? What are the benefits and the costs? Let’s Hash it out.

Site Isolation Protects against Spectre and Meltdown attacks

Let’s start right from the top with Spectre (and Meltdown) attacks, what they are, and why they’re important to protect against. We wrote a full guide last year, but here’s the abridged version:

Spectre and Meltdown are two names for different variants of the same exploit. They take advantage of a vulnerability that affects pretty much every computer chip made for the past two decades. At the end of last year when the two attacks were disclosed, chipmakers around the world rushed to create patches.

There are technically, three variants. Two are lumped together as Spectre, the other is Meltdown. These attacks take advantage of something called Speculative Execution in order to access parts of memory that would otherwise be protected, and then use timing attacks to discover the values that were stored there.

Speculative Execution is a mechanism that helps a chip work faster. It’s easiest to illustrate this with an example. Say a program is about to offer a binary choice, yes/no, with each answer leading to a different process. Rather than wait on the user to decide, the chip will start computing both functions simultaneously so that it already has a head start, regardless of what the user selects.

The data used during speculative execution is often saved in a CPU cache, which is like a little memory alcove that helps speed up fetching data from RAM.

Now, to tie this all together, Spectre and Meltdown are attacks that take advantage of chips’ speculative execution feature, and use timing attacks to expose data that was loaded during that process and then dumped in the CPU cache.

Ok, so how do Spectre and Meltdown affect the browsers?

The problem that Google, and any other browser-maker faces is that Spectre and Meltdown can enable “untrustworthy code” to potentially read any memory in its process’s address space.

As Google’s Charlie Reis puts it in a blog post:

This is particularly relevant for web browsers, since browsers run potentially malicious JavaScript code from multiple websites, often in the same process. In theory, a website could use such an attack to steal information from other websites, violating the Same Origin Policy. All major browsers have already deployed some mitigations for Spectre, including reducing timer granularity and changing their JavaScript compilers to make the attacks less likely to succeed. However, we believe the most effective mitigation is offered by approaches like Site Isolation, which try to avoid having data worth stealing in the same process, even if a Spectre attack occurs.

Got that? To simplify, Spectre attacks can be used, in theory, to steal information from other websites. The Same Origin Policy is a relatively sacrosanct concept in web application security, the idea being that “a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.” Mozilla defines an Origin as:

Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages.

The Same Origin Policy is a cornerstone of browser security. All browsers implement some form of it. Here’s what would happen without it, in the words of Microsoft’s Eric Lawrence:

If content from one origin was able to read content loaded from another origin, one site could easily attack another site. For instance, an IFRAME from attacker.com could read the contents of another IFRAME from yourbank.com. And so forth. The number and scope of attacks against sensitive resources would only be limited by the attacker’s imagination.

So, that’s why the browsers, Google Chrome included, are concerned with Spectre and Meltdown attacks.

What is Site Isolation?

Site Isolation is a little bit more than a new feature given the fact it required the Chromium engineers to alter the browser’s architecture. But it essentially isolates each tab and limits each renderer process to documents from a single site– a single origin.

As Reis writes:

When Site Isolation is enabled, each renderer process contains documents from at most one site. This means all navigations to cross-site documents cause a tab to switch processes. It also means all cross-site iframes are put into a different process than their parent frame, using “out-of-process iframes.” Splitting a single page across multiple processes is a major change to how Chrome works, and the Chrome Security team has been pursuing this for several years, independently of Spectre. The first uses of out-of-process iframes shipped last year to improve the Chrome extension security model.

Unfortunately, even with the Site Isolation feature working, there is still the potential for malfeasance. An attacker’s page could still access and leak information from cross-site URLs if it requests them as sub-resources.

For example browsers typically allow pages to embed images and scripts from any site. So, a page could request an HTML or JSON URL with sensitive data as if it were an image or script. This causes an error on the page and it doesn’t render, but that data still ends up inside the renderer process where a Spectre attack could access it.

So, Site Isolation also includes a feature called Cross-Origin Read Blocking (CORB) as part of its Fetch spec. This feature will block cross-site HTML, XML and JSON responses from from the renderer. Google suggests that web developers check that they are serving resources with the right MIME type and a nosniff response header.

Android users will have to wait for Site Isolation

Although, with the release of Chrome 67, Google has now rolled this change out to 99% of its desktop users, it’s Android users will have to wait until they upgrade to Chrome 68 later this month before they can activate an experimental version of it.

Site Isolation can be enabled manually on Android using:

chrome://flags/#enable-site-per-process.

Google did not give a reason for the delay beyond, “there are additional known issues.” We have a guess though…

The downside of site isolation is the increased memory cost

There’s an additional cost associated with Site Isolation on Google Chrome. Because, by the very nature of Site Isolation, more processes are being run simultaneously, more memory is used up, too. 10-13% more memory overhead is used on real workloads.

Google kind of glosses over this in its blog post, and for many users running new machines with 4GB or more worth of RAM, it likely won’t be a major problem. But for anyone on an older desktop, this could cause a litany of issues.

Google Chrome is already an expensive browser from a memory standpoint. And there’s nothing wrong with that, because it’s a trade-off for greater security. By all accounts Google Chrome is one of, if not the safest browser available to the maintsream public. And Site Isolation is more of the same, it makes users safer but gobbles up even more memory.

This is purely conjecture, but I would guess that may be the hang up with the mobile version of the feature. Until Google can better optimize it to reduce the stress it puts on memory, many phones will be unable to support it and Chrome for Android will have too many problems.

Is Site Isolation worth it?

At the point Google makes a security setting the default, it’s typically done for good reason. The company may do some shady stuff with regard to its ad networks, but it’s security team has noble intentions and spends plenty of time researching and testing these kinds of upgrades before rolling them out.

What I’m saying is it’s still OK to trust Google on security, and this feature protects against a couple of very serious attacks. So yes, I would say for the vast majority of users it’s going to be worth it to leave the feature alone.

The one exception would be users on older machines that lack resources and computing power to allocate Chrome another 10-13%. In your case, I might want to test the feature out and if it’s not working out, you can save some memory by configuring it to only isolate certain sites:

Use command line flags to start Chrome with –isolate-origins followed by a comma-separated list of origins to isolate.  For example:

--isolate-origins=https://google.com,https://youtube.com

You can also choose to toggle the setting off.

As always, leave any questions or comments below!

• #Google
• #Google Chrome
• #Meltdown
• #Site Isolation
• #Spectre