Q1 Summary from Chrome Security
Andrew R. Whalley
Greetings and salutations,
It's time for another update from your friends in Chrome Security, who are hard at work trying to make Chrome the most secure platform to browse the Internet. Here’s a recap from last quarter:
Our Bugs-- effort aims to find (and exterminate) security bugs. In order to get bugs fixed faster, we released a new tool to improve developer experience when trying to reproduce ClusterFuzz bugs. We have overhauled a significant part of the ClusterFuzz UI which now feature a new fuzzer statistics page, crash statistics page and fuzzer performance analyzer. We’ve also continued to improve our OSS-Fuzz offering, adding numerous features requested by developers and reaching 1000 bugs milestone with 47 projects in just five months since launch.
Members of the Chrome Security team attended the 10th annual Pwn2Own competition at CanSecWest. While Chrome was again a target this year, no team was able to demonstrate a fully working chain to Windows SYSTEM code execution in the time allowed.
Bugs still happen, so our Guts effort builds in multiple layers of defense. Chrome 56 takes advantage of Control Flow Guard (CFG) on Windows for Microsoft system DLLs inside the Chrome.exe processes. CFG makes exploiting corruption vulnerabilities more challenging by limiting valid call targets, and is available from Win 8.1 Update 3.
Site Isolation makes the most of Chrome's multi-process architecture to help reduce the scope of attacks. The big news in Q1 is that we launched --isolate-extensions to Chrome Stable in Chrome 56! This first use of out-of-process iframes (OOPIFs) ensures that web content is never put into an extension process. To maintain the launch and prepare for additional uses of OOPIFs, we fixed numerous bugs, cleaned up old code, reduced OOPIF memory usage, and added OOPIF support for more features (e.g., IntersectionObserver, and hit testing and IME on Android). Our next step is expanding the OOPIF-based <webview> trial from Canary to Dev channel and adding more uses of dedicated processes.
Beyond the browser, our web platform efforts foster cross-vendor cooperation on developer-facing security features. Over the holidays, Google's security team gave us a holiday gift consisting entirely of interesting ways to bypass CSP's nonces. We've fixed some obvious bugs they uncovered, and we'll continue working with other vendors to harden the spec and our implementations. In other CSP news, we polished a mechanism to enforce CSP on child frames, shipped a `script-sample` property in CSP reports, and allowed hashes to match external scripts. We're also gathering data to support a few dangling markup mitigations, and dropped support for subresource URLs with embedded credentials and legacy protocols.
We also spend time building security features that users see. To protect users from Data URI phishing attacks, Chrome shows the “not secure” warning on Data URIs and intends to deprecate and remove content-initiated top-frame navigations to Data URIs. We also brought AIA fetching to Chrome for Android, and early metrics show over an 85% reduction in the fraction of HTTPS warnings caused by misconfigured certificate chains on Android. We made additional progress on improving Chrome’s captive portal detection. Chrome now keeps precise attribution of where bad downloads come from, so we can catch malware and UwS earlier. Chrome 57 also saw the launch of a secure time service, for which early data shows detection of bad client clocks when validating certificates improving from 78% to 95%.
We see migration to HTTPS as foundational to any web security whatsoever, so we're actively working to drive #MOARTLS across Google and the Internet at large. To help people understand the security limitations of non-secure HTTP, Chrome now marks HTTP pages with passwords or credit card form fields as “not secure” in the address bar, and is experimenting with in-form contextual warnings. We’ll remove support for EME over non-secure origins in Chrome 58, and we’ll remove support for notifications over non-secure origins in Chrome 61. We talked about our #MOARTLS methodology and the HTTPS business case at Enigma.
In addition to #MOARTLS, we want to ensure more secure TLS through work on protocols and the certificate ecosystem. TLS 1.3 is the next, major version of the Transport Layer Security protocol. In Q1, Chrome tried the first, significant deployment of TLS 1.3 by a browser. Based on what we learned from that we hope to fully enable TLS 1.3 in Chrome in Q2.
In February, researchers from Google and CWI Amsterdam successfully mounted a collision attack against the SHA-1 hash algorithm. It had been known to be weak for a very long time, and in Chrome 56 dropped support for website certificates that used SHA-1. This was the culmination of a plan first announced back in 2014, which we've updated a few times since.
As ever, many thanks to all those in the Chromium community who help make the web more secure!
Cheers
Andrew, on behalf of the Chrome Security Team
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.