Google recently rolled out Chrome 67, and has now revealed this version of the Google browse significantly expands the use of site isolation, one of the key mitigations for web-based Spectre CPU speculative execution attacks that were revealed in January.
Site isolation, which runs one site per process, remains in trial phase for now but Google has with Chrome 67 rolled it out to 99 percent of users. That’s despite it being unable to eradicate the higher memory usage it caused — of between 10 to 20 percent when it first introduced it as an option for some users in Chrome 63 in December, just before the Meltdown and Spectre bugs were publicly disclosed.
The project page and current status is available here and explains that Chrome engineers are attempting to address higher memory usage caused by additional renderer processes. This can happen when many tabs are opened. For a more detailed explanation of why Google chose to work on site isolation for over a decade Justin Schuh, the engineering lead for Chrome Security has the answers.
Despite some remaining memory overheads, the Chrome team has decided its stable enough for most users to roll it out to 99 percent of Chrome 67 users on Windows, Mac, Linux and and Chrome OS. Previously it was gradually expanding the feature.
The specific risk for browsers caused by Spectre is that a an attack can use CPU speculative execution to access normally protected parts of memory, allowing bad code to read any memory in its process’ address space. That’s particularly bad for sites that rely on JavaScript code from multiple websites.
“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,” writes Charlie Reis, Chome’s Site Isolator.
“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
There are pros and cons to Google’s approach to site isolation. Each renderer process is smaller and short lived, but Google hasn’t figured out how to cut down the memory overhead below 10 percent, the lower limit where it was in Chrome 63 due to the larger number of processes. in Chrome 66 it was between 10 to 13 percent.
Either way, Google argues that if a Spectre attack on Chrome were to ever occur — and none has happened yet —the threat wold be significantly educed.
Read more: Why Cisco doesn’t disclose flaws for months after it patches them
The next stage if work on site isolation will focus on bringing the mitigation to Android, Enterprise admins can use experimental polices for doing this in the forthcoming Chrome 68 on Android via chrome://flags/#enable-site-per-process.