Chrome rolls out new protections preventing password and data theft
Google is temporarily increasing the rewards it pays for hacks that exploit holes in a beefed-up security protection that debuted in desktop versions of Chrome last month. Chrome for Android, meanwhile, is receiving a slimmed-down version of the same protection.
For a limited time, Google will boost its normal bounty amounts for exploits that allow one site the browser is interacting with to steal passwords or other sensitive data from another accessed site. Google is also broadening its vulnerability reward program to include bugs in Blink—the core software that Chrome uses to render HTML and other resources—that allow similar types of cross-site data thefts.
Fortress of solitude
The changes come a month after the release of Chrome 77, which quietly strengthened an existing protection known as site isolation. Google developers first added site isolation in July 2018 in a highly ambitious engineering feat that required major architectural changes to the way the browser worked under the hood.
Like other browsers, Chrome previously mixed JavaScript and other content from two or more open sites into a single process. That design left open the possibility of an attacker website accessing sensitive data associated with another website through vulnerabilities known as Spectre and Meltdown. These vulnerabilities reside in virtually every modern processor, and they exploit a performance enhancement known as speculative execution.
As its name suggests, site isolation limits each Blink renderer process to contents from a single site. That way—even if a malicious site is able to bypass Spectre and Meltdown mitigations processor makers have added to their chips over the past 20 months—attacking websites won’t be able to access any data that’s worth stealing.
Beginning in desktop versions of Chrome 77, site isolation now protects not just against attacks targeting speculative execution, it also protects against even more severe attacks that occur when Blink is fully compromised through a memory corruption flaw or some other sort of security bug.
In a post detailing the change, Google engineers Alex Moshchuk and Lukasz Anforowicz wrote:
For example, suppose an attacker discovered and exploited a memory corruption bug in Chrome’s rendering engine, Blink. 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.
In Chrome 77, Site Isolation helps protect many types of sensitive data from such compromised renderer processes:
- Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site.
- Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, JSON, PDF) from a process, even if that process tries to lie to Chrome’s network stack about its origin. Resources labeled with a Cross-Origin-Resource-Policy header are also protected.
Stored data and permissions: Renderer processes can only access stored data (e.g., localStorage) or permissions (e.g., microphone) based on the process’s site lock.
- Cross-origin messaging: Chrome’s browser process can verify the source origin of postMessage and BroadcastChannel messages, preventing the renderer process from lying about who sent the message.
Now that the rollout is done, Google is tweaking its bug bounty program to create incentives for researchers to find and privately report bugs in the new protection.
What about mobile?
So far, site isolation has remained unavailable for iOS and Android versions of Chrome. Now that’s beginning to change, albeit slowly.
Chrome 77 for Android introduced a limited form of site isolation. It applies only to websites where users enter passwords. The reason for limiting the protection to such a small fraction of sites is the performance hit. As on desktop versions, site isolation causes Chrome to create more processes that can consume as much as 5% more memory. That penalty can be much more severe when using devices with limited amounts of memory. In Thursday’s post, the Google engineers explained:
We wanted to ensure that Site Isolation does not adversely affect user experience in a resource-constrained environment like Android. This is why, 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. More specifically, 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.
Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation. That means the site will be rendered in its own dedicated renderer process, walled off from other sites. Navigations to other sites will cause a tab to switch processes, and cross-site iframes are put into a different process, becoming “out-of-process iframes.” Chrome keeps a list of isolated sites stored locally on the device and clears the list whenever users clear their browsing history or other site data. To bootstrap, Chrome also isolates a crowdsourced list of sites where mobile users have been entering passwords most frequently.
Password-triggered site isolation has been enabled for 99% of Android devices running Chrome 77 and having at least 2GB of RAM. Google is holding back the 1% of installations to monitor and improve performance. Android users can enable site isolation for all websites by accessing this URL, but Thursday’s post warns that move will come at a performance cost that may not be acceptable for many people.
Site isolation for iOS versions of Chrome, meanwhile, remains unavailable. Per Apple’s long-standing requirements, Chrome for iOS relies on the Webkit engine, which doesn’t support the out-of-process iframes or other elements of site isolation.
