Q1 Summary from Chrome Security

151 views
Skip to first unread message

Andrew R. Whalley

unread,
May 14, 2018, 5:35:15 PM5/14/18
to chromi...@chromium.org, securi...@chromium.org, ChromeSecurity, securit...@chromium.org, site-isol...@chromium.org

Greetings and salutations,


It's time for another update from your friends in Chrome Security, who are hard at work trying to keep Chrome as the most secure platform to browse the Internet. We'd also like to welcome our colleagues in Chrome OS security to this update - you'll be able to hear what they've been up to each quarter going forward.


In our effort to find and fix bugs, we collaborated with the Skia team and integrated 21 fuzz targets into OSS-Fuzz for continuous 24x7 fuzzing on Skia trunk. So far, we have found 38 security vulns! We also added several new fuzz targets as part of a 2-week bug bash (e.g. multi-msg mojo fuzzer, audio decoder fuzzer, appcache manifest parsing fuzzer, json fuzzer improvements, etc) and found an additional vulnerability through code review. We added libFuzzer support for Chrome OS and integrated it with ClusterFuzz. Sample puffin fuzzer found 11 bugs (includes 2 security). We made several improvements to AFL fuzzing engine integration and fuzzing strategies. This brings it on-par with libFuzzer in terms of the number of bugs found -- it's now ~3X more productive than before!  We added support for building MSan instrumented system libraries for newer debian distros (1, 2).


To help users infected with unwanted software, we moved the standalone Chrome Cleanup Tool into Chrome. Scanning and cleaning Windows machines can now be triggered by visiting chrome://settings/cleanup. There was some misunderstanding on Twitter about why Chrome was scanning, which we clarified. We also pointed people to the unwanted software protection section of Chrome's privacy whitepaper so they can understand what data is and isn’t sent back to Google.


In our effort to move the web to 100% HTTPS, we announced that Chrome will start marking all HTTP pages with a Not Secure warning in July. This is a big milestone that concludes a multi-year effort to roll out this warning to all non-secure pages. Alongside that announcement, we added a mixed content audit to Lighthouse, an automated tool for improving webpage quality. This audit helps developers find and fix mixed content, a major hurdle for migrating to HTTPS. We also announced the deprecation of AppCache in nonsecure contexts.


In addition to MOAR TLS, we also want more secure and usable HTTPS, or BETTER TLS. With that goal in mind, we made changes to  get better metrics about features intended to help users with client or network misconfigurations that break their HTTPS connections (like our customized certificate warnings). We also added more of these “helper” features too: for example, we now bundle help content  targeted at users who are stuck with incorrect clocks, captive portals, or other configuration problems that interfere with HTTPS. Finally, we started preparing for Chrome’s upcoming Certificate Transparency enforcement deadline by analyzing and releasing some metrics about the state of CT adoption so far.


To help make security more usable in Chrome, we’re exploring how URLs are problematic. We removed https/http schemes and www/m subdomains from the steady-state omnibox, and we’re studying the impact of removing positive security indicators that might mislead or distract from the important security information in the origin.


Chrome OS Security had a busy Q1. The vulnerabilities known as Meltdown and Spectre were disclosed in early January, and a flurry of activity followed as we rushed to patch older kernels against Meltdown in Chrome OS 66, and incorporated Spectre fixes for ARM Chrome OS devices in Chrome OS 67. We also started codifying our security review guidelines in a HOWTO doc, to allow the larger Chrome OS team to better prepare for security reviews of their features. Moreover, after being bit by symlinks and FIFOs being used as part of several exploit chains, we finally landed symlink and FIFO blocking in Chrome OS 67. On the hardware-backed security front, we've split off the component that allows irreversible once-per-boot decisions into its own service, bootlockboxd. Finally, work is nearing completion for a first shipping version of a hardware-backed mechanism to protect user credentials against brute force attacks. This will allow PIN codes as a new authentication mechanism for Chrome OS meeting our authentication security guidelines, and we'll use it to upgrade password-based authentication to a higher security bar subsequently.


Spectre kept us busy on the Chrome Browser side as well. The V8 team landed a large number of JIT mitigations to make Spectre exploits harder to produce, and high resolution timers like SharedArrayBuffer were temporarily disabled; more details on our response here. In parallel, the Site Isolation team significantly ramped up efforts to get Site Isolation launched as a Spectre mitigation, since it helps avoid having data worth stealing anywhere in a compromised process. In Q1, we substantially improved support for the Site Isolation enterprise policies that launched prior to the Spectre disclosure, including:

  • Reducing total memory overhead from 20% to 10%.

  • Significantly improving input event handling in out-of-process iframes (OOPIFs).

  • Significantly improving DevTools support for OOPIFs.

  • Adding ChromeDriver support for OOPIFs.

  • Adding support for printing OOPIFs.

  • Improving rendering performance for OOPIFs.

  • Starting standards discussions for Cross-Origin Read Blocking (CORB).

Thanks to these improvements, we have been running field trials and are preparing to launch the strict Site Isolation policy on desktop.  We talked about much of this work at this week’s Google I/O.


Finally, we continue to work on exploit mitigations and other security hardening efforts. For example, Oilpan, blink's garbage collecting memory management system, removed its inline metadata, which make it more difficult to overwrite with memory corruption bugs. This was the culmination of several years of effort, as performance issues were worked through. In Android P, we refactored the WebView zygote to become a child of the main app_process zygote, reducing memory usage and helping with the performance of future Site Isolation efforts. Members of Platform Security also helped coordinate the response to Spectre and Meltdown, and still managed to find time to conduct their routine reviews of new Chrome features.


For more thrilling security updates and feisty rants, subscribe to securi...@chromium.org. You can find older updates at https://dev.chromium.org/Home/chromium-security/quarterly-updates.



Reply all
Reply to author
Forward
0 new messages