Q2 2024 Summary from Chrome Security
Adrian Taylor
Greetings,
This is what the Chrome Security team have been doing in the second quarter of 2024.
Real-time phishing protection for Safe Browsing is now rolling out on Android (Desktop and iOS landed last quarter), bringing >25% more phishing protection. We’ve switched desktop users to asynchronous checks, which removes any performance impact of these real-time checks while retaining the protective value.
In extension safety, we published a blog detailing our efforts and what users can do to stay safe. Additionally, we added several more triggers in Chrome that will flag unwanted or unexpected extensions for the user in the Safety Check.
In the cookie theft space, we launched auto-deep scanning of suspicious downloads for ESB users, and expanded the encrypted-archive scanning as an option for standard-SB users.
We fully launched post-quantum TLS key exchange on Chrome Desktop platforms, and it is now used in 19-26% of all forward-secret HTTPS connections. We also added a device policy to disable it on the login screen for managed ChromeOS devices. We blogged about some of the challenges in deploying post-quantum cryptography, and explained our strategy of focusing on agility.
We’ve added support for certificate revocations due to key compromise to CRLSet, and enabled enforcement. Any certificate revoked with the key compromise reason code should now be blocked by Chrome clients within 24-48 hours. This approach should work for day-to-day revocation, but will not work for mass revocation events, due to a limit on the max size of a CRLSet.
The Chrome Root Program announced the distrust of two CAs—e-commerce Monitoring GmbH and Entrust—for compliance failures. Both distrusts used a new gradual approach to distrust, where certificates logged to a Certificate Transparency log prior to a well defined enforcement date continue to be trusted until expiry.
Within the CA/Browser Forum, the Chrome Root Program contributed to Ballot SC-75 (passed), which focused on linting. This ballot was partially motivated by “Moving Forward, Together" and the wide-spread certificate mis-issuance detected by our team in the Spring. We also continued pushing forward with Ballot SC-67 (moving to vote on approximately 7/15), which is focused on strengthening security practices via multi-perspective domain validation. At CA/Browser Forum Face-to-Face, we presented our expectations around incident response.
The Chrome Security Architecture team reached an exciting milestone in Q2, enabling isolated sandboxed frames by default! This adds a process boundary between origins and untrustworthy content they host, and it required solving numerous challenges with srcdoc URLs, data URLs, base URLs, and other corner cases. We also shipped RenderDocument for all subframes, ensuring that a new RenderFrameHost is consistently used for each new subframe document. We added several new security enforcements against compromised renderer processes as well, including opaque origin checks and expanding the new CanCommitURL checks to Android WebView. To prepare for future experiments, we made progress on Origin Isolation and SiteInstanceGroup modes. Finally, we expanded our memory-safe browser kernel model in Rust to simulate documents, navigations, and session history.
On Windows, the platform security team has continued work on app-bound encryption support for cookies. The first stages of this project are being rolled out through the release channels now. Work has also begun on expanding this protection to other secrets.
The ACG mitigation for the browser process on Windows, which was previously only behind a feature flag, was promoted to a new enterprise policy, and we encourage folks to try it out and report any incompatibilities.
On macOS, we are continuing to refine our approach to ad-hoc PWA signing. We have a new solution which we believe ought to interoperate well with all sorts of deployed host security software, and are now finalizing enterprise policies and other deployment requirements before we ship this.
We have brought the Skia font manager to our PDF reader, allowing us to strengthen the PDF sandbox, and we have made changes in several areas of Chromium to enable compiler protection against unsafe buffer uses. We have also continued our long-term architectural work to port ANGLE to target Dawn, which is partly complete but unlikely to be finished this year.
The Offensive Security team discovered and reported two high-severity bugs in Chrome.
Spanification, one of our Safe Coding projects, made significant progress in Q2. We have updated almost all APIs in //base and //net so they can take buffers as spans. Thanks to our infrastructure work in Q1, we can roll out the -Wunsafe-buffers warning incrementally across the codebase, and as of the end of Q2 Chrome has files comprising 1.5 million lines of non-test code that are protected by that warning and are therefore less likely to have out-of-bounds access bugs introduced in the future. Our process and docs are mature enough we're ready for early-adopter teams to start Spanifying their code; to that end, we made a formal announcement to chromium-dev about the project and its goals.
As for MiraclePtr, we are at a stage to start the roll out to the renderer process. And as part of that work we have been especially focused on investigating the performance overhead of MiraclePtr. We now have bots and a dashboard to monitor the overhead over time so as not to introduce raw_ptr into performance hot spots.
Earlier this year the Chrome Security team stood up automation to build a CodeQL database for Chrome once a day. This quarter we started engaging more proactively with GitHub to identify and drive fixes in CodeQL's C++ extractor (e.g. this issue) that have led to incomplete CodeQL databases.
Early this quarter we launched the V8 Sandbox VRP alongside a technical blog post about the sandbox. While the V8 sandbox is still in development and not yet considered a security boundary, the VRP inclusion is an important step towards that goal. In May we then also presented about the sandbox at OffensiveCon in Berlin. On the CFI-side, we investigated an approach for forward-edge CFI based on memory protection keys which appears promising as it has very low performance overhead. We are now aiming to use it to achieve forward-edge CFI for both JavaScript- and WebAssembly calls. Finally, helped by events such as Pwn2Own or the V8CTF (our exploit bounty program), we collected some statistics about the types of bugs being exploited in V8.
The Chrome Fuzzing team continues work on two fronts: writing novel fuzzers and maintaining the tools and infrastructure used by Chromium engineers to write and run fuzzers.
We landed truly automated IPC fuzzing, which found a bug, though a couple infra bugs remain. We are experimenting with integration of Chrome and Fuzzilli and an accessibility tree based UI fuzzer. We also considered an experiment to unblock coverage-guided fuzzers using AI/LLMs.
On the infrastructure side, we have been working to diversify and expand our fuzzing fleet with newer devices. We are investing in aligning our fleet management with the rest of chrome test infrastructure to reduce operational toil and allow us to grow the fleet further next year.
After months of behind the scenes work and integration, the Chrome VRP, in conjunction with Google VRP, launched the new payments integration with Bugcrowd, resulting in a more flexible option for reward payments for all VRPs across Google, including Chrome VRP.
The Chrome VRP has also been working on forthcoming updates to the Chrome VRP reward structure as well as working on plans for upcoming VRP events, including the BugSWAT events in Las Vegas in August (in conjunction with Black Hat USA, Def Con, and Google’s 0x0G event) and as part of the annual ESCAL8 event in October in Málaga, Spain.
Until next time,
Adrian
On behalf of Chrome Security