Q2 2020 Summary from Chrome Security

67 views
Skip to first unread message

Andrew R. Whalley

unread,
Aug 28, 2020, 4:26:55 PM8/28/20
to Chromium-dev, Security-dev, ChromeSecurity, securit...@chromium.org, site-isol...@chromium.org

Greetings,


The 2nd quarter of 2020 saw Chrome Security make good progress on multiple fronts, all helping to keep our users, and the web safe.


The Chrome Safe Browsing team launched real-time phishing protection for all Android devices, and observed a 164% increase in phishing warnings for main-frame URLs. We also completed the rollout of Enhanced Safe Browsing to all users of Chrome on desktop platforms.


We helped the Chrome for iOS team implement hash-based Safe Browsing protection in Chrome 84 for iOS for the first time ever. Also working with various teams, most notably the Mobile UX, we made significant progress in shipping Enhanced Safe Browsing in Chrome 86 for Android.


For desktop platforms, we landed changes to the in-browser phishing detection mechanism to help reduce phishing false negatives using new machine learning models for Chrome 84 and beyond. We also finalized the plan to disable more malicious Chrome Extensions, starting with Chrome 85.


The Enamel team put the finishing touches on our work to prevent https:// pages from loading insecure content. We built a new warning for https:// pages with forms targeting insecure endpoints, and prepared to start rolling out mixed download warnings in Chrome 84. This release will also include mixed image autoupgrading and the second phase of TLS 1.0/1.1 deprecation.


Even on an https:// website, users need to accurately understand which website they’re visiting. We expanded our lookalike domain warning with new triggering heuristics, and prepared to launch an additional warning (pictured) for lower-precision heuristics in M86.


The Platform Security team continued to make good progress on many of our longer term projects, including sandboxing the network service (and associated certificate verification servicification), adopting Oilpan garbage collection in PDFium's XFA implementation, and investigating memory safety techniques, and exploitation mitigation technologies.


Along with our colleagues in Chrome Security Architecture, we've sharpened the security focus on Mojo, Chrome's IPC system, and started looking at what's needed to improve developer ergonomics and make it easier to reason about communicating over security boundaries. Also with CSA, we've worked on how MiraclePtr could help prevent use after free bugs in C++ code.


Bugs-- continued to develop and improve the FuzzBench platform which has helped the security research community develop more efficient fuzzing engines (HonggFuzz, AFL++ got several improvements and leads the benchmarking results). Based on FuzzBench results, we have successfully integrated Entropic as a fuzzing strategy in ClusterFuzz. We have started rewriting/improving several Chrome blackbox fuzzers (e.g. dom, webbot, media, ipc), and also deprecated ~50 duplicate/unneeded fuzzers. In OSS-Fuzz service, we added first-class fuzzing support for Golang and Rust languages (better compiler instrumentation, crash parsing, and easier project integration) and improved CI (e.g. Honggfuzz checks). Lastly, we worked closely with Android Security and improved ClusterFuzz for on-device and host fuzzing use cases (e.g. syzkaller support, pixel hardware fuzzing).


The Open Web Platform Security team remained focused on mitigating injection attacks on the one hand, and improving isolation of sensitive content on the other. Q2 was exciting on both fronts!


We shipped an initial implementation of Trusted Types, which gives developers the ability to meaningfully combat DOM XSS, and nicely compliments CSP's existing mitigations against other forms of injection. Google has deployed Trusted Types in high-value applications like My Google Activity, and we're excited about further rollouts.

We also rolled out our first pass at two new isolation primitives: Cross-Origin Opener Policy and Cross-Origin Embedder Policy. Opting-into these mechanisms improves our ability to process-isolate your pages, mitigating some impacts of Spectre and XSLeaks, which makes it possible to safely expose powerful APIs like SharedArrayBuffers.


The Chrome Security Architecture team has started Origin Trials for opt-in origin isolation, allowing origins to use separate processes from the rest of their site. We have also made progress on securing extension content script requests and enforcements for request initiators, and we improved the update mechanism for Android Site Isolation's list of isolated sites. Much of Q2 was spent on cleanup and documentation, though, particularly test infrastructure and flaky test improvements. Finally, we also contributed to MiraclePtr efforts to reduce memory bugs, and we helped more teams use WebUI by adding support for web iframes.


In the world of the Web PKI, TLS certificates issued from default-trusted CAs after 2020-09-01 will be rejected if their lifetime is greater than 398 days, beginning with Chrome 85. See the documentation and FAQ. This is part of a number of changes adopted by CA/Browser Forum with unanimous support from major Browsers, which aligns the Baseline Requirements with many existing Browser root program requirements. 


We continued informal cross-browser collaboration and met with the European Union on their eIDAS Regulation, exploring how certificates can be used to provide identity information for domains in a manner consistent with the Web Platform.


Until next time, on behalf of Chrome Security, I wish you all the very best.


Andrew

Reply all
Reply to author
Forward
0 new messages