2020 Q4 Summary from Chrome Security
Andrew R. Whalley
Greetings,
Even as 2021 is well underway, here's a look back at what Chrome Security was up to in the last quarter of 2020.
Interested in helping to protect users of Chrome, Chromium, and the entire web? We're hiring! Take a look at g.co/chrome/hiring, with several of the roles in Washington, DC: g.co/chrome/securityprivacydc.
The Usable Security team fully launched a new warning for lookalike domain names: low-quality or suspicious domains that make it hard for people to understand which website they’re actually visiting. We continued to place some final nails in the coffin of mixed content (insecure subresources on secure pages). Secure pages are no longer allowed to initiate any insecure downloads as of Chrome 88. We uncovered some issues with our new warning on mixed form submissions due to redirects, and this warning will be re-launching in Chrome 88 as well.
With HTTPS adoption continuing to rise, it’s now time to begin treating https:// as the default protocol, so we began implementing a change to the Chrome address bar to default to https:// instead of http:// if the user doesn’t type a scheme. Stay tuned for more information about this change in Q1.
To improve the security of the Certificate Transparency (CT) ecosystem, we began dogfooding an opt-in approach to audit CT information seen in the wild, and we started designing improvements to make this approach more resilient.
The Chrome Safe Browsing team helped the Chrome for iOS team roll out real-time Safe Browsing protections in Chrome 86 for iOS. Also, in addition to our existing mechanism to disable malicious Chrome Extensions with a large install base, we rolled out a new mechanism that allows us to also disable malware extensions with a small install base.
On the memory safety front, we've been getting ready to ship Oilpanned XFA and continue to engage with the MiraclePtr and *Scan project. As those initiatives are treating the symptom rather than the cause, we continue to investigate what a safer dialect of C++ would look like, and to improve Rust/C++ interoperability ahead of any possible future rust experiments. Ongoing work on exploit mitigations includes Control-flow Enforcement Technology, GWP-ASan, and Control Flow Guard.
We’re also working on reducing the privilege of the network service sandbox on Windows. We’re planning to do the same on Android later in the year.
FuzzBench continues to help the research community benchmark and create more efficient fuzzing engines (e.g. AFL++ 3.0, SymQEMU, etc). We added support for bug-based benchmarking (sample report), fuzzer stats api, saturated corpora testing. Our OSS-Fuzz platform now has first-class support for Python fuzzing, and continues to grow at a brisk pace (~400 projects, 25K+ bugs). Based on community feedback, we created a lightweight, standalone ClusterFuzz python package (alpha) for common fuzzing use cases, e.g. stacktrace parsing. We have refactored AFL fuzzing integration to use the engine interface. We have been working on a solution to better track vulnerabilities in third-party dependencies. We have also bootstrapped several open source security efforts under the OpenSSF foundation, e.g. security scorecards, finding critical projects, etc.
We implemented blocking of requests from insecure contexts to private networks (first part of CORS-RFC1918), and are analyzing metrics to chart a path to launch.
We introduced the PolicyContainer to squash bugs around inheritance of security policies to about:blank, srdoc or javascript documents.
We also implemented a first version of a Sanitizer API and started the specification process.
With CrossOriginOpenerPolicy (COOP) and CrossOriginEmbedderPolicy (COEP) launched, we were able to re-enable SharedArrayBuffers on Android gated behind crossOriginIsolated (a.k.a COOP+COEP), which Firefox has also done. We have a plan to deprecate all SAB usage without crossOriginIsolated in Chrome 91 (with reverse Origin Trial until Chrome 93).
This will require users of SharedArrayBuffers to adopt COOP and COEP. Adopting COEP has proved difficult. We have heard that the deployment of COEP was difficult for a certain number of websites that embed third-party content. We are considering a new form of COEP that might alleviate those issues: credentialless. To help drive adoption of COOP we moved the COOP reporting API out of Origin Trial to on by default in Chrome 89.
We have started to collect metrics on dangerous web behaviors, with the hope of driving them down. The first one we’ll likely be looking at is document.domain.
The Security Architecture team completed the CORS for content scripts migration in Chrome 87, removing the allowlist for older extensions and strengthening Site Isolation for all desktop users! Opt-in origin isolation was renamed to Origin-Keyed Agent Clusters and is on track to launch in Chrome 88. We are making progress towards additional Android Site Isolation for OAuth and COOP sites, and we helped secure SkBitmap IPCs against memory bugs. Finally, we have been investing in architecture changes, including SiteInfo to better track principals and SiteInstanceGroup to simplify the process model, along with significant reviews for Multiple Page Architecture and Multiple Blink Isolates.
Cheers,
Andrew, on behalf of the Chrome security team