Q4 2023 Summary from Chrome Security
Adrian Taylor
Hello,
Here are some of the things Chrome Security has been working on in Q4 of last year.
To continue to combat the problem of Cookie Theft, we started offering the ability to scan suspicious passphrase-encrypted archives via Google servers for users who have enabled Enhanced Safe Browsing in Chrome. We also launched a refresh of the various types of download warnings shown in Chrome to make them consistent and understandable, and that, along with prior launches, has successfully lowered the warning click-through rate in H2’23.
We’re also working on protecting Chrome users even after they’ve gotten malware. We’ve been iterating on the design and implementation of the Device Bound Sessions Credentials (DBSC) API, which will allow sites to bind cookies to the device (without enabling tracking), and make it much harder for malware to do harm at scale.
To help protect Chrome’s locally-encrypted secrets from similar-privileged processes, we’re adding app-bound encryption on Windows and starting with cookies. Most of the mechanics of that encryption have landed and we expect to begin experimenting with it soon.
In our ongoing efforts to preemptively prevent quantum computers from destroying the internet, we continued to gradually roll out postquantum TLS key exchange. After getting experiment results, we implemented some performance optimizations to the underlying cryptographic algorithm. We published a proposal called TLS Trust Expressions and presented it at IETF in Prague. This proposal aims to improve the agility and robustness of the web PKI, and also ties into our previous Merkle Tree Certificates proposal that may be able to reduce the number of huge postquantum signatures needed on the wire to establish fully postquantum-secure TLS connections.
We launched new warnings on HTTP downloads, to help protect users from network attackers who might inject malicious binaries or other content into downloads. This is an expansion of our previous effort to block “mixed” downloads, or HTTP downloads initiated from HTTPS pages.
Finally, we finished porting Chromium’s certificate verifier into BoringSSL (Google’s cryptography/TLS library), and adapted Chromium to use the new BoringSSL version. After further development of a public API, this BoringSSL port will provide an alternative to the legacy OpenSSL certificate verifier for other users of BoringSSL.
We launched OAC-by-default, which deprecates document.domain by default, removing one of the footguns of the Web Platform. We participated in Interop discussions with other browser vendors around TrustedTypes, and Mozilla is now positive about the spec. Some organizations are interested in the spec being implemented in all browsers as they hope it will allow them to comply with imminent regulatory changes in the Netherlands and the broader EU, as outlined in the eIDAS Regulation (which restricts the usage of an upcoming EU identity mechanism to pages that do not use “eval”).
The Chrome Security Architecture team made good progress on security architecture improvements in Q4. The first RenderDocument field trial (for "non-local-root subframes") reached stable channel, and the compositor reuse field trial for remaining cases reached beta channel. We also finished the base URL inheritance launch and fixed most remaining issues for isolated sandboxed iframes to unblock a beta trial, which is now in progress. Citadel mode is now enabled everywhere to provide better protections against unlocked renderer processes. We're also excited that OAC-by-default is now fully launched, so that document.domain changes are blocked by default and we are free to experiment with Origin Isolation. Finally, we ran a team hackathon to clean up and simplify existing code, such as in ChildProcessSecurityPolicy.
The Platform Security team focused on continuing rollouts of the features we developed earlier this year. Our main priority was continuing the rollout of the network service sandbox to Windows, Linux, and ChromeOS platforms. For Windows, we're most of the way to fully supporting the Direct Socket API with the network service sandbox, which is a blocker for further experimentation; for Linux and ChromeOS, we're investigating performance issues on low-memory devices with the sandbox enabled.
We also continued work on adhoc PWA signing; during early Q4 we encountered an incompatibility between adhoc signing and Santa, a binary authorization system for macOS. While we're working on resolving that, rollout of adhoc PWA signing has been paused.
In the last three months of this year we reached important milestones in our efforts to improve memory safety in Chrome. First, we expanded the launch of our first Rust-backed product feature – in-process QR code generation – to 100% of the Stable (non-ChromeOS) population after experiments showed significant (95%+) reductions in 95th-percentile generation times with no negative impact on any topline metrics. That rollout helped us validate our Rust toolchain across all supported platforms and we were able to announce that the Rust toolchain is production-ready as of Chrome 119.
Elsewhere in memory safety, we were able to enable GWP-ASAN on Android which massively improves our insight into memory safety bugs that might get hit in the wild. We are also laying the groundwork for addressing the class of out-of-bounds memory access vulnerabilities through broader use of base::span in the Chromium codebase: we added APIs to improve ergonomics and started updating existing APIs to track lengths where they hadn't before.
The V8 security team has continued the development of the V8 sandbox and CFI, as well as improved our open-source fuzzer, Fuzzilli. On the sandbox side, we shipped the trusted space for V8 this quarter and migrated BytecodeArrays into it, resolving a long-standing sandbox blocker. Since then, we’ve also migrated the trusted parts of the WasmInstanceObject (another long-standing issue), and expect to migrate further objects soon. For CFI, we worked on a number of under-the-hood changes, for example a refactoring of the way V8 manages heap chunks to be able to use the new mseal syscall to seal all executable memory in the future. Finally, in October we launched the V8CTF and soon after received the first successful submission!
In Q4, the infra security team rolled out a number of security changes to secure the Chromium code base, including the 2P committer review change which requires two persons to review code authored by someone who is not a Chromium committer.
We also deployed an automated pipeline called CPESuggest that creates automated CLs to add Common Platform Enumerations to our README.chromium metadata files so we can better keep on top of identifying CVEs which might affect our third party dependencies.
In our bug-zapping team, DEET, we’ve been polishing the things we did in Q3. For instance our fuzzing coverage dashboard now much more accurately represents the percent of Chromium code which is really covered by fuzzers (about 22% - please add fuzzers!) We also succeeded in running fuzz cases on more modern Android devices using hwasan which can detect more types of security bugs. We’ve continued to work on making centipede work reliably in Chrome, and especially worked on the complex “InProcessFuzzers” which in future will allow fuzzing in a realistic browser_test-like environment. Work has also been continuing apace on rearchitecting ClusterFuzz to enable running untrusted workloads safely. There is one new thing this quarter - we’ve been experimenting with FuzzTest and we’re starting to see new FuzzTest fuzz targets be added. These are simpler and quicker to write than the old libfuzzer technology, though they’re not yet supported on as many platforms.
The Chrome VRP had the opportunity to meet up with some of our top researchers from past and present years in Tokyo for our BugSWAT event as part of ESCAL8 2023. BugSWAT 2023 was three days of talks, live hacking, and socializing with VRP researchers and Googlers from other VRPs across Google. We also just recently announced our Top 20 VRP reporters for 2023, celebrating the achievements of the Chrome VRP researcher community this year.
We’ve also been heavily preparing for Chromium’s imminent move to a new issue tracker, which changes our world radically!
Finally, lots of different parts of Chrome Security came together to meet with various graphics teams to chart a course towards simplifying our graphics architecture in future and ensuring all the remaining attack surface is fuzzed to the extent possible.
Until next time,
Adrian
On behalf of Chrome Security