Q4 2022 Summary from Chrome Security

123 views
Skip to first unread message

Andrew R. Whalley

unread,
Feb 21, 2023, 5:04:37 PM2/21/23
to Chromium-dev, Security-dev

Greetings,


With 2023 well underway, here's a look back at what the Chrome Security team got up to in the last quarter of last year.


After multiple years of laying policy and engineering groundwork, Chrome’s built-in certificate verifier and root store launched on Chrome for Windows and Mac – bringing both security and performance benefits. Chrome’s recently launched root program governs the certificates that are included in the root store, and this quarter we continued to refine Chrome’s root program policies and improve workflows for CA applicants, particularly through Common CA Database integration. To help keep users safe and ensure the integrity of certificates accepted by Chrome, we announced that Chrome will no longer trust the TrustCor CA as of Chrome 111.


Want more HTTPS in your life? On Canary and Dev, you can now enable the #https-upgrades and #https-first-mode-v2 at chrome://flags to tell Chrome to automatically attempt all your navigations over HTTPS. You can also enable #block-insecure-downloads to protect yourself from any download delivered over an insecure connection.


We’ve been working to bring Chrome for iOS users the same transport security features as Chrome has on other platforms, with HTTPS-First Mode, omnibox HTTPS upgrading, and mixed content autoupgrading all in various stages of launch on Chrome for iOS.


We shipped iframe credentialless in Chrome 110, allowing developers to easily embed iframe in COEP environments, even if they don’t deploy COEP themselves.


We started applying Private Network Access checks to web workers. Currently, they only trigger warnings, except for fetches within dedicated workers in insecure contexts. We are looking at launching enforcement when we better understand metrics.


The deprecation of document.domain — enabling origin-based Agent Clustering by default — is still on track. We are receiving a low-frequency stream of issues around the deprecation, as site owners notice document.domain is going away. We're working through these, and so far nothing appears to be blocking. With a bit of luck we will be able to finish this on the current schedule, in Chrome 112 or 113.


The first step of moving from CORB to ORB — ORB "v0.1" — is now enabled on 50% of stable, with no reported issues. We'd previously landed a fix for SVG images, and the last known origin mismatches between the browser and renderer processes. This makes us confident that we can launch "v0.2" next, which will change error handling to be conforming to the ORB proposal.


The Chrome Security Architecture team wrapped up 2022 by shipping Site Isolation for <webview> tags, one of the few remaining places on desktop platforms that didn't have locked renderer processes. We also locked third party New Tab Page processes as we got closer to fully enabling "citadel-style" enforcements everywhere, so that unlocked processes won't have any access to protected sites. Finally, we made steady progress on other necessary architecture work, including base URL inheritance, RenderDocument, and SiteInstanceGroup, including support for local frame swaps and speculative RenderViewHosts.


The Platform Security team continues to work on sandboxing the Network Service across several platforms. On Linux-based OSes, we made proxy resolution asynchronous; and we are doing the same for UDP connection initiation, which is needed for brokering those sockets from the browser process. On Windows, we added a mitigation to restrict sending writable file handles to executable files to low-privileged processes and filtered potentially-sensitive environment variables from such processes, as well as blocking some more pipes from being accessible, as well as continued work on making the sandbox process startup faster. We also worked to integrate the V8 memory cage improvements into PDFium and worked with the BackupRefPtr team on additional improvements to pointer safety. And finally on Mac, we started rolling out performance improvements to sandbox initialization.


In memory safety news, we have announced a new policy for using Rust in Chromium, which has been getting some good press. We’re working on productionizing the Rust toolchain, which means making the compiler available on all of our development platforms (Linux, Windows, Mac), and the ability to cross-compile for Android/iOS/etc. And we have been working with partners to bring our first uses of Rust into Chromium.


We’ve continued building toward automated C++ bindings to Rust libraries, building out the design of the tool, implementing function calls, and addressing some difficult safety design topics.


C++ reference members are now protected by BackupRefPtr: We created, and executed a clang plugin to rewrite them as raw_ref<T>


We ran an experiment banning callbacks invoked with dangling pointers. It reached canary and dev. Discovered violations were listed and fixed in part by the code health rotation. The plan is to enable it by default after reaching stable.


We identified every pre-existing dangling raw_ptr in tests. It will allow us to start enforcing the DanglingPointerDetector on the CQ in 2023Q1.


A new clang GC plugin is now banning some problematic unsafe patterns of GC objects owning non-GC objects. 


The V8 Security team landed many improvements to Fuzzilli, our JavaScript engine fuzzer, such as new mutators and support for more language features. We shipped the External Pointer Table for the V8 Sandbox in Chrome 107 and started working on code pointer sandboxing - further design and prototype work around CFI for V8.


The Chrome Offensive Security team continued our deep dive into Chromium graphics acceleration with an emphasis on inter-process communication (IPC) channels, namely the Dawn Wire protocol introduced by WebGPU and the enduring Command Buffer protocol. We filed two high severity security bugs, both found through manual analysis. Beyond IPC, we started an audit of Tint, the WebGPU shader compiler. We also made good progress writing two new fuzzers, one for Dawn Wire and the other for the Command Buffer, which will land separately in 2023Q1. We're excited to integrate them for cross-protocol fuzzing. 


The Chrome Vulnerability Reward Program updated our policies and rewards. One of the changes was the introduction of a Bisect Bonus, following which we've seen an increase in the reporting of bisections provided by reporters. We are now receiving bisects as part of VRP reports in up to 40% of reports some weeks, but at a general average of 27%. This has reduced the amount of manual reproductions required by Security Sheriffs during bug triage to determine how far back bugs reproduce in active release channels. 


The Chrome VRP also wrapped up another unparalleled year with a total of $4 million awarded to VRP researchers in 2022. $3.5 million was awarded to researchers for 363 reports of security bugs in Chrome Browser and $500,000 for 110 reports of security bugs in ChromeOS. To help show our appreciation for helping keep Chrome more secure in 2022, in collaboration with Google VRP, we sent end of year gifts to our top 22 Chrome VRP Researchers for 2022, and publicly celebrated their achievements.


Meanwhile, the Smithy team — working on security tooling — automated CVE information submission so that enterprises can get a reliable feed of security bugs we’ve fixed.


Until next time,


Andrew

On behalf of Chrome Security


Reply all
Reply to author
Forward
0 new messages