Q2 2023 Summary from Chrome Security

[Andrew R. Whalley]

Greetings,

I'm pleased to share an update on some of the things the Chrome Security team has been up to in the 2nd quarter of the year.

In addition to much behind the scenes work, the Chrome Counter Abuse team disabled the “--load-extension” flag for Enhanced Safe Browsing users to remove a common and easy technique to silently load malicious extensions.  We also added support to scan additional archive types for malware, include those that are nested.

The Trusty Transport team advanced our years-long march towards ubiquitous HTTPS. We announced a major milestone: the upcoming removal of the address bar lock icon in Chrome 117. We’re now experimenting on stable with silently upgrading all navigations to HTTPS (falling back to HTTP if the upgrade fails).

We continue to improve the technologies underlying HTTPS via the Chrome Root Program and our BoringSSL library. We integrated the postquantum-secure X25519Kyber768 key encapsulation mechanism for TLS into BoringSSL and Chrome, and plan to begin experimenting with it in Chrome 116. The Chrome Root Store is now launched on stable for all platforms except iOS, bringing significant performance improvements to Android in particular. On the policy fronts, we passed a CA/Browser Forum ballot to incentivize short-lived and automated certificates and promote more privacy-preserving revocation infrastructure, and we distrusted the e-Tugra root certificates after a researcher discovered significant security issues in their systems.

The Web Platform Security team started an OT for a new COOP mode (restrict-properties) in Chrome 116. This allows websites to deploy cross-origin isolation, unlocking access to powerful web features, as well as secure themselves against cross-site leaks. On the road to enabling origin isolation, deprecating document.domain (aka Origin-keyed Agent Clustering by Default), is now enabled on 1% stable, and will keep ramping up to 100%. ORB (Opaque Response Blocking) v0.1 shipped to stable, improving on CORB to better protect cross-origin subresources from Spectre attacks. ORB v0.2 was scoped down to avoid web compatibility concerns and align with Firefox. We sent the I2S and are aiming to ship soon. Implementation continues on a new permission prompt allowing secure websites to bypass mixed content when accessing the private network. We are aiming to start an OT with an MVP in Chrome 117.

The Security Architecture team made progress on several launch experiments in Q2, aimed at improving security. The new base URL inheritance rules were approved and are in a beta field trial, which allowed us to restart the experiment for Site Isolation for sandboxed iframes. The trials for RenderDocument and navigation queueing are also in progress. In parallel, we built a new mode for origin isolation (OriginKeyedProcessesByDefault) built on top of OAC-by-default, with plans for performance experiments, and started work on a SiteInstanceGroup mode that uses a separate SiteInstance in the same group for data: URLs. We also made some improvements to BrowserContext lifetime to reduce the risk of use-after-frees. Finally, we started work on a new early RenderFrameHost swap approach to replace the old early commit optimization, and formed a navigation bug triage rotation to better manage the queue of bugs.

The Platform Security team continues to make progress on sandboxing the network service. UDP sockets can now be brokered into the sandbox, which will be used on Android and Windows. An initial network service sandbox policy was developed for Linux. On Mac, we audited use of CFPreferences within the sandbox. And on Windows we worked on removing unnecessary device handles from the renderer sandbox. With project Sandbake, we worked on improvements to the dangling pointer detector and investigated improvements to raw_ptr flags. We also revisited some of the memory limits on renderers and were able to unblock some Web Assembly use-cases without impacting memory usage or performance. In addition, work was done on hardening the renderer process against attacks on kernel devices such as \device\cng and some general continued sandbox refactoring including adding a generic capability to preload DLLs needed by sandboxed processes before the sandbox fully engages.

The OffSec team finished and circulated our WebGPU analysis documents internally within Chrome, which led to ongoing engagement with graphics colleagues. We're particularly proud of two impactful engagements:

• A fix for SwitchShader that squashes 4 bug variants and also led to insightful discussion with graphics colleagues.

• Collaboration with Android and partners to verify the fix for crbug.com/1420130 reported in Q1. 

We did several presentations about attacking Chrome, including a quick summary of our WebGPU findings for Parisa Tabriz, a Learning Lunch about fuzzing Chrome with partners at Intel, and a Mojo bug walk-through at a sandbox escape analysis session with our colleagues in the Chrome Security Architecture team. Speaking of attacking Chrome, we continue to find and report security bugs (crbug.com/1431761 , crbug.com/1430985, crbug.com/1430221)  as well as landing new automation to find bugs in areas of interest, such as this protobuf-mutator fuzzer for Dawn, which landed upstream after a multi-quarter review process. Finally, we hosted the inaugural Browser Vulnerability Research Summit, with much gratitude to colleagues at Google, Webkit, Microsoft and Mozilla who made it possible by participating and establishing an atmosphere of collaboration. 

In memory safety news, MiraclePtr (BackUpRefPtr) is now enabled by default for Linux, macOS, and ChromeOS, following its previous enabling for Windows and Android last year. Usage of MiraclePtr (i.e. raw_ptr<T>) is now enforced for most code using a clang plugin.

The Lightweight Use-after-Free Detector experiment has demonstrated the potential to make use-after-free bug reports more actionable, and progress is being made to ship it. The DanglingPointerDetector experiment on the CQ concluded with positive feedback, and was made permanent. Coverage has been extended for all tests. It has been enabled by default on Linux/Debug, and under build flags for others.

Rust support is now enabled for all bots and developers, and we’re shipping chrome://crash/rust toward Stable on all platforms with Blink in Chrome 117.

A Rust-based QR Code generator will also be shipping in Chrome 117 behind a finch flag on Android, Windows, MacOS, and Linux (ChromeOS on Chrome 118) for experimenting with a real Rust feature. It will replace an asynchronous out-of-process C++ component with a synchronous in-the-browser-process Rust implementation.

In Q2, the V8 Security team continued to improve Fuzzilli, our JavaScript engine fuzzer. With the refactored HybridEngine, it is now possible to build “mini-fuzzers” on top of Fuzzilli, for example for fuzzing regular expressions or data serialization. A full changelog of all Fuzzilli changes can be found here. On the CFI side, we laid the foundation for JIT validation by tracking JIT-code regions in PKEY-protected memory, and for the V8 sandbox, we worked on a design to protect code pointers that should be performance neutral. Last but not least, we began refactoring the_hole in V8 to mitigate vulnerabilities that leak this internal value to JavaScript code.

In Q2, the Chrome VRP launched the Full Chain Exploit Bonus – until 1 December 2023, the first report of a full chain exploit in Chrome is eligible for triple the full reward amount, and any subsequent report of a full chain is eligible for double the full reward amount. MiraclePtr was enabled across Linux, Mac, and ChromeOS in M115, with that MiraclePtr protected non-renderer UAFs are now considered to be highly mitigated security bugs. In parallel to this change, we launched the MiraclePtr Bypass Reward, offering a $100,115 reward for an eligible submission of a MiraclePtr bypass.

In fuzzing, we’ve been building upon the new possibilities of Centipede by experimenting with a browser_test-based fuzzing target framework. The hope is that this will enable us to fuzz the whole of Chrome in a realistic fashion, while also getting the benefits of coverage guidance, though this is still quite experimental. We’ve been working on a Chrome UI fuzzer using this technology. We’ve also reinstated a Chrome fuzzing coverage dashboard - please look for gaps and submit fuzzers! We’ve also been preparing for the new Chromium issue tracker.

Until next time,

Andrew

On behalf of Chrome Security