Q3 2023 Summary from Chrome Security
Adrian Taylor
Hello!
We’d like to share a few things that Chrome Security has been doing in the third quarter of 2023.
In the Counter Abuse team, we launched the overhauled Download UX to 100% (popular in the press)! The new UX provides a platform to build a number of security-focussed features, including many to counter the abuse via cookie theft.
In the extensions safety space, we launched the “Extension Module” in the Safety Hub to help users remove unwanted extensions, and the launch was well received by the press (e.g. The Verge, Engadget).
Within the Trusty Transports team, we’ve been working on TLS post-quantum key agreement which is currently rolling out to 1% Stable. This quarter we resolved server incompatibilities that appeared while on Beta and we are now proceeding with a gradual rollout. We also published an IETF draft to ease future compatibility and security problems with upcoming post-quantum transitions. Elsewhere in the TLS stack, we fully launched Encrypted Client Hello (ECH), in partnership with Mozilla, Cloudflare, and the IETF, and we completed the removal of SHA1 in signatures in the handshake.
We announced an upcoming iteration of our root program policy, focusing on requiring automation for new applicants, as previously explored in our Moving Forward Together roadmap. We blogged about why automation is critical for a secure and agile PKI. To improve the robustness of the web PKI’s Certificate Transparency (CT) infrastructure, we announced a significant update to our CT log monitoring tooling, which will allow us to detect many more types of CT log issues before they have broader ecosystem impact.
After a gradual rollout, we fully launched HTTPS upgrading in Chrome 117, which automatically attempts all plaintext navigation over HTTPS, and silently falls back to plaintext HTTP if the upgrade fails. This helps protect against passive eavesdropping, and marks a notable step in our continued march to make plaintext an aberration on the web. Along those lines, the replacement of the lock icon started to make its debut on Chrome Stable.
Finally, we hosted interns who made some improvements to our HSTS preload infrastructure. One of these improvements was automatically pruning sites from the list if they stop meeting the requirements for an extended period of time, which will help keep the list size more manageable.
In Q3, the Web Platform security team launched an Origin Trial for COOP restrict-properties. COOP restrict-properties allows a web page to limit its interactions while supporting OAuth and payments popups. It protects against a variety of XS-Leaks. If the page deploys COEP, it is also crossOriginIsolated. We believe this will make the deployment of crossOriginIsolation much easier, allowing web pages to gain access to powerful APIs like SharedArrayBuffers safely. We’ve also made progress on the Sanitizer API, and have a general agreement with other browser vendors on the shape of the API we want to build.
In Q3, the Security Architecture team spent significant effort designing a possible early RFH swap to unload one document before another commits, to unblock a potential feature. We also fixed crashes to unblock the base URL inheritance and isolated sandboxed iframes launches, and we helped respond to issues from the OAC-by-default rollout (to unblock origin isolation). In RenderDocument, we realized it would be necessary to reuse compositors across documents, so we started work on that and launched a "non-local-root subframe" experiment group for cases that aren't affected. We also made progress on giving data: URLs their own SiteInstances within SiteInstanceGroups, as a step towards always having an accurate SiteInstance even in shared processes.
In Q3, the Platform Security team focused our efforts on improving our sandboxes, researching and prototyping uses of new OS security primitives, and providing security guidance and leadership throughout Chrome (including security review, consultation, other ad-hoc engagements with other teams, and a very well-received public blog post).
The main sandbox improvements from Q3 were in the network service sandbox, including designing (but not yet implementing) a solution for the Direct Sockets web API and brokering some other APIs. We also raised the Windows sandbox memory limit to enable more WASM features, and reduced the renderer's access to KsecDD and fonts on Windows.
The main new OS security primitive work was implementing ad-hoc code signing of PWAs on Mac and adopting LPAC & NTFS ioctl mitigations on Windows after convincing Microsoft to add them. We also did a considerable amount of research on the Windows VBS Enclave API and started prototyping for future use.
We also had a couple of lowlights this quarter: we had to stop work on the Android network service sandbox after it became clear the resource usage would be too high to justify having a network service process, and we didn't manage to get Kerberos brokering on ChromeOS done, which leaves a big sandbox hole on that platform.
Offensive Security released a technical report describing our approach to attacking WebGPU in Chrome. We hope the report gives Chrome Vulnerability Rewards Program participants a boost to help us keep Chrome 0-day hard. Our ad hoc research also led to discovery and fixes for two vulnerabilities: crbug.com/1464680 (Critical) and crbug.com/1479104 (High), which will be de-restricted per the usual 14-week disclosure process.
We completed support for the myriad of Chromium build configurations in the Rust toolchain, with the public announcement of readiness to ship Rust code coming just shortly into Q4. The Rust-backed QR Code generator experiment has made its way to Stable on our largest platforms with 10% of users making use of the Rust implementation, and no stability or other issues identified. The last platform is ChromeOS where it has now reached beta without any issues. Our next steps will be to improve the process for updating third-party dependencies, our supply chain security processes, and sharing of third-party dependencies with our downstream projects such as Skia.
DanglingPointerDetector coverage continues to grow. It is now enabled by default for developers on Linux, and a PRESUBMIT was added to discourage developers cargo-culting the dangling pointer annotations over fixing the dangling pointers. Coverage has been expanded to all test types, except on Android. It has also been enabled on ChromeOS Ash which checks 7,742 more pointers, and uncovered 2,076 more dangling pointers that are now annotated. We organized 2 code health rotation projects to fix and remove dangling pointers.
PartitionAlloc repository can now be fetched and included from arbitrary locations. This will allow our downstream projects such as Skia and Dawn to make use of it. We have written out plans to adopt MiraclePtr (through PartitionAlloc) in Dawn and Angle. We concluded the experiment around rewriting vector<T*> to vector<raw_ptr<t>> and decided to proceed with the rewrite.
In Q3, the V8 Security team worked on CFI, the_hole mitigations, and on sandboxing. On the CFI side, we enabled PKEY-based code protection on supported platforms and have started to work on code validation. Read more about our CFI plans in this recent blog post. We also worked on more domain-specific mitigations, in particular to mitigate the effect of the_hole leaks, of which there have been a few recently. Next up, on the V8 sandboxing side, we’ve worked on creating a “trusted heap space” that will contain sensitive objects such as bytecode and code metadata that must not be corrupted by an attacker. Find more details in this design document. Finally, we also launched the V8CTF this quarter which is essentially an exploit-bounty for n-day renderer exploits. With that, we hope to get early feedback on our future exploit mitigations such as CFI or the V8 sandbox. Check out the rules here!
Our new bug-finding team is called DEET. In fuzzing, we’ve got three major projects going on: first, we’re upgrading our Android fuzzing devices so we can decommission our old fleet before it literally catches fire, and in the process revisiting our ASAN integration. Secondly, ClusterFuzz is being split so that fuzzers are run on untrusted virtual machines. (Part of our eventual goal here is to allow VRP reporters to upload their test cases directly to ClusterFuzz, though we don’t have a timeframe for that yet). And finally, we’re progressing towards efficient coverage-guided fuzzing of the whole Chromium browser using centipede, with a view to exploring our whole IPC and UI attack surface in future. Finally, we reinstated our Chromium fuzzing code coverage dashboard - please look for gaps and write fuzzers!
In the VRP space, we’ve been helping out with Chrome OS’s launch of an independent Vulnerability Rewards Program. Additionally, we sunset the additional V8 Exploit Bonus (V8 exploit submissions may now be covered by the V8 CTF) and launched the new reward structure for V8 bugs impacting Stable and older versions of Chrome. The goal of the new V8 rewards structure is to incentivize the reporting of long-existing exploitable security issues in V8, which has already resulted in a $30,000 reward for a report of V8 bug that has existed since at least Chrome 91. We’ve also been prepping talks and other engagement activities for the top Chrome VRP researchers invited to ESCAL8 in Tokyo in October 2023.
Lastly, we’re preparing (heavily!) for Chromium’s upcoming change to a new issue tracker.
Until next time,
Adrian
On behalf of Chrome Security