The most ambitious browser mitigation yet for Spectre attacks comes to Chrome

Google’s Chrome browser is undergoing a major architectural change to enable a protection designed to blunt the threat of attacks related to the Spectre vulnerability in computer processors. If left unchecked by browsers or operating systems, such attacks may allow hackers to pluck passwords or other sensitive data out of computer memory when targets visit malicious sites.

Site isolation, as the mitigation is known, segregates code and data from each Internet domain into their own "renderer processes," which are individual browser tasks that aren't allowed to interact with each other. As a result, a page located at arstechnica.com that embeds ads from doubleclick.net will load content into two separate renderer processes, one for each domain. The protection, however, comes at a cost. It consumes an additional 10 to 13 percent of total memory. Some of the performance hit can be offset by smaller and shorter-lived renderer processes. Site isolation will also allow Chrome to re-enable more precise timers, which Google and most other browser makers disabled earlier this year to decrease chances of successful attacks.

Site isolation has been available in Chrome as an optional mitigation since early this year, but starting with version 67, it's being enabled by default for 99 percent of users. Google is leaving it off for the other 1 percent so engineers can monitor and improve performance. The protection is also being enabled in the Chrome desktop. For performance reasons, it isn't available in Chrome for Android for the time being.

An impressive feat

The mitigation is an impressive engineering feat that's designed to lessen the damage of attacks that exploit a new class of vulnerability that came to light in January. Dubbed Spectre, the attack abuses a CPU optimization technique known as speculative execution so that it can obtain passwords, cryptographic keys, and other memory-resident data that normally should be off limits to untrusted pieces of code. The flaw has represented a serious threat to people browsing websites because individual pages often serve JavaScript from multiple domains that run in the same process. That leaves open the possibility that a malicious ad might steal sensitive user data belonging to a site hosting the ad, a hack that would violate a Web security cornerstone known as the same origin policy.

In a blog post published Wednesday, Google engineer Charlie Reis wrote:

Site Isolation is a large change to Chrome's architecture that limits each renderer process to documents from a single site. As a result, Chrome can rely on the operating system to prevent attacks between processes and, thus, between sites. Note that Chrome uses a specific definition of "site" that includes just the scheme and registered domain. Thus, https://google.co.uk would be a site, and subdomains like https://maps.google.co.uk would stay in the same process.

Chrome has always had a multi-process architecture where different tabs could use different renderer processes. A given tab could even switch processes when navigating to a new site in some cases. However, it was still possible for an attacker's page to share a process with a victim's page. For example, cross-site iframes and cross-site pop-ups typically stayed in the same process as the page that created them. This would allow a successful Spectre attack to read data (e.g., cookies, passwords, etc.) belonging to other frames or pop-ups in its process.

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.

Even when each renderer process is limited to documents from a single site, there is still a risk that an attacker's page could access and leak information from cross-site URLs by requesting them as subresources, such as images or scripts. Web browsers generally allow pages to embed images and scripts from any site. However, a page could try to request an HTML or JSON URL with sensitive data as if it were an image or script. This would normally fail to render and not expose the data to the page, but that data would still end up inside the renderer process where a Spectre attack might access it. To mitigate this, Site Isolation includes a feature called Cross-Origin Read Blocking (CORB), which is now part of the Fetch spec. CORB tries to transparently block cross-site HTML, XML, and JSON responses from the renderer process, with almost no impact to compatibility. To get the most protection from Site Isolation and CORB, Web developers should check that their resources are served with the right MIME type and with the nosniff response header.

Site isolation is by far the most ambitious Spectre/Meltdown mitigation deployed by any browser maker so far. To date, most others have disabled the same types of precise timers as Chrome. Those tweaks make it harder for malicious code to successfully pluck sensitive data out of restricted memory. If Google's site isolation works as designed, it goes much further by preventing the mingling of data from different domains in the first place.