Google Security Blog

Mitigating Spectre with Site Isolation in Chrome

Google Security Blog - Wed, 07/11/2018 - 12:15pm
Posted by Charlie Reis, Site Isolator

Speculative execution side-channel attacks like Spectre are a newly discovered security risk for web browsers. A website could use such attacks to steal data or login information from other websites that are open in the browser. To better mitigate these attacks, we're excited to announce that Chrome 67 has enabled a security feature called Site Isolation on Windows, Mac, Linux, and Chrome OS. Site Isolation has been optionally available as an experimental enterprise policy since Chrome 63, but many known issues have been resolved since then, making it practical to enable by default for all desktop Chrome users.

This launch is one phase of our overall Site Isolation project. Stay tuned for additional security updates that will mitigate attacks beyond Spectre (e.g., attacks from fully compromised renderer processes).

What is Spectre?

In January, Google Project Zero disclosed a set of speculative execution side-channel attacks that became publicly known as Spectre and Meltdown. An additional variant of Spectre was disclosed in May. These attacks use the speculative execution features of most CPUs to access parts of memory that should be off-limits to a piece of code, and then use timing attacks to discover the values stored in that memory. Effectively, this means that untrustworthy code may be able to read any memory in its process's address space.

This is particularly relevant for web browsers, since browsers run potentially malicious JavaScript code from multiple websites, often in the same process. In theory, a website could use such an attack to steal information from other websites, violating the Same Origin Policy. 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.

What is Site Isolation?

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, would be a site, and subdomains like 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.
A single page may now be split across multiple renderer processes using out-of-process iframes.
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 a significant change to Chrome's behavior under the hood, but it generally shouldn't cause visible changes for most users or web developers (beyond a few known issues). It simply offers more protection between websites behind the scenes. Site Isolation does cause Chrome to create more renderer 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 10-13% total memory overhead in real workloads due to the larger number of processes. Our team continues to work hard to optimize this behavior to keep Chrome both fast and secure.

How does Site Isolation help?

In Chrome 67, Site Isolation has been enabled for 99% of users on Windows, Mac, Linux, and Chrome OS. (Given the large scope of this change, we are keeping a 1% holdback for now to monitor and improve performance.) This means that even if a Spectre attack were to occur in a malicious web page, data from other websites would generally not be loaded into the same process, and so there would be much less data available to the attacker. This significantly reduces the threat posed by Spectre.

Because of this, we are planning to re-enable precise timers and features like SharedArrayBuffer (which can be used as a precise timer) for desktop.

What additional work is in progress?

We're now investigating how to extend Site Isolation coverage to Chrome for Android, where there are additional known issues. Experimental enterprise policies for enabling Site Isolation will be available in Chrome 68 for Android, and it can be enabled manually on Android using chrome://flags/#enable-site-per-process.

We're also working on additional security checks in the browser process, which will let Site Isolation mitigate not just Spectre attacks but also attacks from fully compromised renderer processes. These additional enforcements will let us reach the original motivating goals for Site Isolation, where Chrome can effectively treat the entire renderer process as untrusted. Stay tuned for an update about these enforcements! Finally, other major browser vendors are finding related ways to defend against Spectre by better isolating sites. We are collaborating with them and are happy to see the progress across the web ecosystem.

Help improve Site Isolation!

We offer cash rewards to researchers who submit security bugs through the Chrome Vulnerability Reward Program. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards levels, up to twice the usual amount for information disclosure bugs. Find out more about Chrome New Feature Special Rewards.
Categories: Google Security Blog

Compiler-based security mitigations in Android P

Google Security Blog - Wed, 06/27/2018 - 5:27pm
Posted by Ivan Lozano, Information Security Engineer

[Cross-posted from the Android Developers Blog]

Android's switch to LLVM/Clang as the default platform compiler in Android 7.0 opened up more possibilities for improving our defense-in-depth security posture. In the past couple of releases, we've rolled out additional compiler-based mitigations to make bugs harder to exploit and prevent certain types of bugs from becoming vulnerabilities. In Android P, we're expanding our existing compiler mitigations, which instrument runtime operations to fail safely when undefined behavior occurs. This post describes the new build system support for Control Flow Integrity and Integer Overflow Sanitization.
Control Flow IntegrityA key step in modern exploit chains is for an attacker to gain control of a program's control flow by corrupting function pointers or return addresses. This opens the door to code-reuse attacks where an attacker executes arbitrary portions of existing program code to achieve their goals, such as counterfeit-object-oriented and return-oriented programming. Control Flow Integrity (CFI) describes a set of mitigation technologies that confine a program's control flow to a call graph of valid targets determined at compile-time.
While we first supported LLVM's CFI implementation in select components in Android O, we're greatly expanding that support in P. This implementation focuses on preventing control flow manipulation via indirect branches, such as function pointers and virtual functions—the 'forward-edges' of a call graph. Valid branch targets are defined as function entry points for functions with the expected function signature, which drastically reduces the set of allowable destinations an attacker can call. Indirect branches are instrumented to detect runtime violations of the statically determined set of allowable targets. If a violation is detected because a branch points to an unexpected target, then the process safely aborts.

Figure 1. Assembly-level comparison of a virtual function call with and without CFI enabled. For example, Figure 1 illustrates how a function that takes an object and calls a virtual function gets translated into assembly with and without CFI. For simplicity, this was compiled with -O0 to prevent compiler optimization. Without CFI enabled, it loads the object's vtable pointer and calls the function at the expected offset. With CFI enabled, it performs a fast-path first check to determine if the pointer falls within an expected range of addresses of compatible vtables. Failing that, execution falls through to a slow path that does a more extensive check for valid classes that are defined in other shared libraries. The slow path will abort execution if the vtable pointer points to an invalid target.
With control flow tightly restricted to a small set of legitimate targets, code-reuse attacks become harder to utilize and some memory corruption vulnerabilities become more difficult or even impossible to exploit.
In terms of performance impact, LLVM's CFI requires compiling with Link-Time Optimization (LTO). LTO preserves the LLVM bitcode representation of object files until link-time, which allows the compiler to better reason about what optimizations can be performed. Enabling LTO reduces the size of the final binary and improves performance, but increases compile time. In testing on Android, the combination of LTO and CFI results in negligible overhead to code size and performance; in a few cases both improved.
For more technical details about CFI and how other forward-control checks are handled, see the LLVM design documentation.
For Android P, CFI is enabled by default widely within the media frameworks and other security-critical components, such as NFC and Bluetooth. CFI kernel support has also been introduced into the Android common kernel when building with LLVM, providing the option to further harden the trusted computing base. This can be tested today on the HiKey reference boards.
Integer Overflow SanitizationThe UndefinedBehaviorSanitizer's (UBSan) signed and unsigned integer overflow sanitization was first utilized when hardening the media stack in Android Nougat. This sanitization is designed to safely abort process execution if a signed or unsigned integer overflows by instrumenting arithmetic instructions which may overflow. The end result is the mitigation of an entire class of memory corruption and information disclosure vulnerabilities where the root cause is an integer overflow, such as the original Stagefright vulnerability.
Because of their success, we've expanded usage of these sanitizers in the media framework with each release. Improvements have been made to LLVM's integer overflow sanitizers to reduce the performance impact by using fewer instructions in ARM 32-bit and removing unnecessary checks. In testing, these improvements reduced the sanitizers' performance overhead by over 75% in Android's 32-bit libstagefright library for some codecs. Improved Android build system support, such as better diagnostics support, more sensible crashes, and globally sanitized integer overflow targets for testing have also expedited the rollout of these sanitizers.
We've prioritized enabling integer overflow sanitization in libraries where complex untrusted input is processed or where there have been security bulletin-level integer overflow vulnerabilities reported. As a result, in Android P the following libraries now benefit from this mitigation:
  • libui
  • libnl
  • libmediaplayerservice
  • libexif
  • libdrmclearkeyplugin
  • libreverbwrapper
Future PlansMoving forward, we're expanding our use of these mitigation technologies and we strongly encourage vendors to do the same with their customizations. More information about how to enable and test these options will be available soon on the Android Open Source Project.
Acknowledgements: This post was developed in joint collaboration with Vishwath Mohan, Jeffrey Vander Stoep, Joel Galenson, and Sami Tolvanen
Categories: Google Security Blog

Better Biometrics in Android P

Google Security Blog - Thu, 06/21/2018 - 2:46pm
Posted by Vishwath Mohan, Security Engineer

[Cross-posted from the Android Developers Blog]

To keep users safe, most apps and devices have an authentication mechanism, or a way to prove that you're you. These mechanisms fall into three categories: knowledge factors, possession factors, and biometric factors. Knowledge factors ask for something you know (like a PIN or a password), possession factors ask for something you have (like a token generator or security key), and biometric factors ask for something you are (like your fingerprint, iris, or face).

Biometric authentication mechanisms are becoming increasingly popular, and it's easy to see why. They're faster than typing a password, easier than carrying around a separate security key, and they prevent one of the most common pitfalls of knowledge-factor based authentication—the risk of shoulder surfing.
As more devices incorporate biometric authentication to safeguard people's private information, we're improving biometrics-based authentication in Android P by:
  • Defining a better model to measure biometric security, and using that to functionally constrain weaker authentication methods.
  • Providing a common platform-provided entry point for developers to integrate biometric authentication into their apps.
A better security model for biometricsCurrently, biometric unlocks quantify their performance today with two metrics borrowed from machine learning (ML): False Accept Rate (FAR), and False Reject Rate (FRR).
In the case of biometrics, FAR measures how often a biometric model accidentally classifies an incorrect input as belonging to the target user—that is, how often another user is falsely recognized as the legitimate device owner. Similarly, FRR measures how often a biometric model accidentally classifies the user's biometric as incorrect—that is, how often a legitimate device owner has to retry their authentication. The first is a security concern, while the second is problematic for usability.
Both metrics do a great job of measuring the accuracy and precision of a given ML (or biometric) model when applied to random input samples. However, because neither metric accounts for an active attacker as part of the threat model, they do not provide very useful information about its resilience against attacks.
In Android 8.1, we introduced two new metrics that more explicitly account for an attacker in the threat model: Spoof Accept Rate (SAR) and Imposter Accept Rate (IAR). As their names suggest, these metrics measure how easily an attacker can bypass a biometric authentication scheme. Spoofing refers to the use of a known-good recording (e.g. replaying a voice recording or using a face or fingerprint picture), while impostor acceptance means a successful mimicking of another user's biometric (e.g. trying to sound or look like a target user).
Strong vs. Weak BiometricsWe use the SAR/IAR metrics to categorize biometric authentication mechanisms as either strong or weak. Biometric authentication mechanisms with an SAR/IAR of 7% or lower are strong, and anything above 7% is weak. Why 7% specifically? Most fingerprint implementations have a SAR/IAR metric of about 7%, making this an appropriate standard to start with for other modalities as well. As biometric sensors and classification methods improve, this threshold can potentially be decreased in the future.
This binary classification is a slight oversimplification of the range of security that different implementations provide. However, it gives us a scalable mechanism (via the tiered authentication model) to appropriately scope the capabilities and the constraints of different biometric implementations across the ecosystem, based on the overall risk they pose.
While both strong and weak biometrics will be allowed to unlock a device, weak biometrics:
  • require the user to re-enter their primary PIN, pattern, password or a strong biometric to unlock a device after a 4-hour window of inactivity, such as when left at a desk or charger. This is in addition to the 72-hour timeout that is enforced for both strong and weak biometrics.
  • are not supported by the forthcoming BiometricPrompt API, a common API for app developers to securely authenticate users on a device in a modality-agnostic way.
  • can't authenticate payments or participate in other transactions that involve a KeyStore auth-bound key.
  • must show users a warning that articulates the risks of using the biometric before it can be enabled.
These measures are intended to allow weaker biometrics, while reducing the risk of unauthorized access.
BiometricPrompt APIStarting in Android P, developers can use the BiometricPrompt API to integrate biometric authentication into their apps in a device and biometric agnostic way. BiometricPrompt only exposes strong modalities, so developers can be assured of a consistent level of security across all devices their application runs on. A support library is also provided for devices running Android O and earlier, allowing applications to utilize the advantages of this API across more devices .
Here's a high-level architecture of BiometricPrompt.

The API is intended to be easy to use, allowing the platform to select an appropriate biometric to authenticate with instead of forcing app developers to implement this logic themselves. Here's an example of how a developer might use it in their app:

ConclusionBiometrics have the potential to both simplify and strengthen how we authenticate our digital identity, but only if they are designed securely, measured accurately, and implemented in a privacy-preserving manner.
We want Android to get it right across all three. So we're combining secure design principles, a more attacker-aware measurement methodology, and a common, easy to use biometrics API that allows developers to integrate authentication in a simple, consistent, and safe manner.
Acknowledgements: This post was developed in joint collaboration with Jim Miller
Categories: Google Security Blog