Google strengthens Chrome's site isolation to protect browser against its own vulnerabilities
Credit to Author: Gregg Keizer| Date: Thu, 31 Oct 2019 04:49:00 -0700
Google is telling Chrome users that it has extended an advanced defensive technology to protect against attacks exploiting vulnerabilities in the browser’s Blink rendering engine.
Chrome 77, which launched in September but was supplanted by Chrome 78 on Oct. 22, received the beefed-up site isolation, wrote Alex Moshchuk and Łukasz Anforowicz, two Google software engineers, in an Oct. 17 post to a company blog. “Site Isolation in Chrome 77 now helps defend against significantly stronger attacks,” the two said. “Site Isolation can now handle even severe attacks where the renderer process is fully compromised via a security bug, such as memory corruption bugs or Universal Cross-Site Scripting (UXSS) logic errors.”
As the label implies, Chrome’s site isolation limits each Blink rendering engine process to documents from a single website, thus isolating everything in a rendered site from other sites. The idea is that if a malicious website exploits a vulnerability, the hackers controlling the attack site won’t be able to access any data, say extremely valuable corporate data, outside of their own criminal website.
When Google fully implemented site isolation in mid-2018 (a year after it debuted) with Chrome 67, the technology’s primary purpose was to defend against the Spectra-style attacks envisioned when in-chip vulnerabilities were revealed earlier that year.
That’s now changed.
“Suppose an attacker discovered and exploited a memory corruption bug in Chrome’s rendering engine, Blink,” Moshchuk and Anforowicz said. “The bug might allow them to run arbitrary native code within the sandboxed renderer process, no longer constrained by the security checks in Blink. However, Chrome’s browser process knows what site the renderer process is dedicated to, so it can restrict which cookies, passwords, and site data the entire process is allowed to receive. This makes it far more difficult for attackers to steal cross-site data.”
For example, when site isolation of the renderer is activated, cookies and passwords can only be accessed by those processes “locked” to their corresponding sites.
There was cause to extend site isolation to cover Blink’s rendering processes. “Past experience suggests that potentially exploitable bugs will be present in future Chrome releases,” the Google-led Chromium team acknowledged in documentation. “There were 10 potentially exploitable bugs in renderer components in M69, 5 in M70, 13 in M71, 13 in M72, 15 in M73. This volume of bugs holds steady despite years of investment into developer education, fuzzing, Vulnerability Reward Programs, etc. Note that this only includes bugs that are reported to us or are found by our team.”
M69, M70 and so on are the Chromium labels for Chrome 69, Chrome 70, etc.
Chrome 77’s additional site isolation capabilities were foreshadowed last year by Justin Schuh, principle engineer and director of Chrome security, when he tweeted, “…work is under way to protect against attacks from compromised renderers.”
At the same time, Schuh said that, while engineers are working up site isolation for Chrome on Android, that’s also unfinished because of “resource consumption issues.” That consumption was one of the prime trade-offs for implementing site isolation, as increasing the number of processes increased the browser’s memory consumption by up to 13%.
As of Chrome 77, the Android version also sports site isolation, Moshchuk and Anforowicz said in their post two weeks ago. The technology wasn’t enabled the same way as on desktop personal computers, though.
“Unlike desktop platforms where we isolate all sites, Chrome on Android uses a slimmer form of Site Isolation, protecting fewer sites to keep overhead low, wrote Moshchuk and Anforowicz. “Site Isolation is turned on only for high-value sites where users log in with a password. This protects sites with sensitive data that users likely care about, such as banks or shopping sites, while allowing process sharing among less critical sites.”
That password-triggered site isolation has been switched on for nearly all – 99%, said Moshchuk and Anforowicz – on Android devices with at least 2GB of system memory.
More information about Chrome’s site isolation – a lot more – can be found in a paper that Moshchuk, along with two Google colleagues, Charles Reis and Nasko Oskov, presented in August at the annual USENIX Security Symposium.
Site isolation has been – or will be – taken up by other browsers. Count Opera, of course, among the former, as the Norwegian browser relies on the fruits of Chromium, the open-source project that produces the technologies, site isolation among them, that power Chrome.
In February, Mozilla said its own “Project Fission” would add site isolation to Firefox but did not spell out a timetable. It’s unclear what progress Mozilla has made since then – an initial newsletter from the Fission engineering group was never supplanted by one newer – but developers have reduced the memory Firefox requires for a typical process, a necessary step if site isolation isn’t to cripple the browser with performance hits.
Microsoft, which late in 2018 dumped the homegrown browser technologies behind Edge for Chromium’s, will almost certainly feature site isolation when it eventually debuts a stable version of the so-called “full-Chromium” Edge.
Not surprisingly, Google remains hot on site isolation. Very hot.
“I’m not exaggerating when I call site isolation the single greatest advance in browser security since the creation of the sandbox,” tweeted Google’s Schuh on Oct. 17. “It has fundamentally changed the kinds of guarantees the browser can provide and sets the strongest security baseline of any real-world platform.”