33
Recent Site Isolation improvements
source link: https://chinagdg.org/2019/10/recent-site-isolation-improvements/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Recent Site Isolation improvements
Source: Recent Site Isolation improvements from Chromium
In July 2018 we launched Site Isolation in Chrome as a way to secure desktop browsers against the risk of side-channel attacks like Spectre. We recently published a USENIX Security conference paper highlighting the benefits of this launch. Today, we are pleased to announce further improvements we’ve rolled out in Chrome 77:
- Chrome for Android has enabled Site Isolation for sites where users enter passwords.
- On desktop platforms, Site Isolation now helps defend against attacks from fully compromised renderer processes, not just side-channel attacks.
Site Isolation on Android
Chrome 77 has brought Site Isolation and its benefits to Android users. Like Site Isolation on desktop, this launch leverages OS processes to make it harder for attackers to steal data from other websites. In particular, it offers the most effective defense against Spectre-like CPU vulnerabilities.
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.
For the most part, Site Isolation is a behind-the-scenes architectural change that should not change the experience for users or developers. As on desktop platforms, it does cause Chrome to create more processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 3-5% total memory overhead in real workloads. We continue to work hard to optimize this behavior to keep Chrome both fast and secure.
In Chrome 77, password-triggered Site Isolation has been enabled for 99% of users (with a 1% holdback to monitor and improve performance) on Android devices that have a sufficient amount of RAM (currently 2GB). While we investigate how to bring this support to more devices, users who desire the most complete protection for their devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.
In the future, we plan to add support for more ways of detecting when a site should be protected by Site Isolation. For example, we’re working on allowing website operators to opt in any site to Site Isolation, without requiring user login.
Containing Compromised Renderers
On desktop platforms, Site Isolation in Chrome 77 now helps defend against significantly stronger attacks. Our initial launch targeted Spectre-like attacks which could leak any data from a given renderer process. 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.
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.
We are continuing to improve compromised renderer protections in several ways:
- Bringing these protections to Chrome for Android. This requires extra work to handle the case where only certain sites are isolated.
- Protecting CSRF defenses.Sec-Fetch-Site and Origin request headers can be verified to prevent compromised renderers from forging them.
- Protecting more types of data. We are investigating how to protect additional data types by default with Cross-Origin Read Blocking.
- Removing exceptions. We are working to remove cases where these protections may not yet apply. For example, a small set of extensions still have broader cross-site access from content scripts, until they update to the new security model. We have already worked with extension authors to bring the affected Chrome user population down from 14% to 2%, as well as harden other extension security issues. Also, Site Isolation does not apply to Flash, which is currently disabled by default and is on a deprecation path.
We’re excited about the improvements this brings to Chrome’s overall security model. As a result, we are broadening the scope of the Chrome Vulnerability Reward Program to also cover cross-site data disclosure attacks that involve compromised renderers. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards than the usual amount for information disclosure bugs. We are grateful for the contributions from security researchers that we have received so far, and we look forward to working together further to improve the state of web security.
Posted by Alex Moshchuk and Łukasz Anforowicz, Site Isolators
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK