Q4 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. As it's the start of 2018, we reflected on a year’s worth of security improvements, and announced new stats around our VRP and Safe Browsing warnings.
Here are some highlights from the last quarter of 2017:
In effort to find and fix bugs, we (Bugs--):
Wrote a new and easily extensible javascript fuzzer using Babel, which found 100+ bugs in both V8 (list) and other browser javascript engines (list).
Started integrating Clang Source-based Code Coverage in the Chromium build system and are deprecating Sanitizer Coverage. Clang coverage is very precise, shows hit frequencies and is much easier to visualize. You can follow progress here.
Hosted a month long fuzzathon in October where Chromium developers participated in writing new fuzz targets and fixing blockers for existing ones. This resulted in 93 bugs, several of which were in new uncovered areas of codebase; results here.
Fixed several bugs in our automated owner and component assignment pipeline and expanded our buildbot infrastructure to archive builds more frequently, for more accurate blame results. Faster and more accurate bug triaging means faster fixes for users!
Other than fixing bugs, we (MOAR TLS, Enamel, Safe Browsing) also:
Blogged about the massive uptick in HTTPS we saw in 2017: 71 of the top 100 sites on the Web use HTTPS by default, up from 37 a year ago. We also announced our continuing platinum sponsorship of Let’s Encrypt.
Delivered a change (in M62, announced in April), extending the “Not Secure” omnibox warning chip to non-secure pages loaded while Incognito and to non-secure pages after the user edits a form field.
Added an enterprise policy (in M65) for treating insecure origins as secure contexts, to help with development, testing, and intranet sites that are not secured with HTTPS.
More tightly integrated Chrome’s captive portal detection with operating system APIs. This feature helps users log in to captive portals (like hotel or airport wifi networks) rather than seeing unhelpful TLS certificate errors.Launched predictive phishing protection to warn users when they’ve typed their Google password into a never-seen-before phishing site.
As always, we invest a lot in security architecture and exploit mitigations. Last quarter, we (Platform Security / Site Isolation):
Started rolling out the Mac Sandbox v2, bringing both greater security and cleaner code.
Refactored sandbox code out of //content to make it easier to use across the system.
Worked on and helped coordinate Chrome's response to the recently announced Spectre and Meltdown CPU vulnerabilities and worked with the V8 team who spearheaded Chrome's Javascript and WebAssembly mitigations which are rolling out to users now.
Accelerated the rollout of Site Isolation as a mitigation for Spectre/Meltdown. Enabling Site Isolation reduces the amount of valuable cross-site data that can be stolen by such attacks. We're working to fix the currently known issues so that we can start enabling it by default.
Implemented cross-site document blocking in (M63) when Site Isolation is enabled. This ensures that cross-site HTML, XML, JSON, and plain text files are not given to a renderer process on subresource requests unless allowed by CORS. Both --site-per-process and --isolate-origins modes are now available via enterprise policy in Chrome 63.
Ran field trials of --site-per-process and --isolate-origins on 50% of Chrome Canary instances to measure performance, fix crashes, and spot potential issues. In a separate launch involving out-of-process iframes and Site Isolation logic, https://accounts.google.com now has a dedicated renderer process in Chrome 63 to support upcoming requirements for Chrome Signin.
We have landed a large number of functional and performance improvements for Site Isolation, including fixes for input events, DevTools, OAuth, hosted apps, crashes, and same-site process consolidation which reduces memory overhead.
To help users that inadvertently installs unwanted software, we (Chrome Protector):
Launched new Chrome Cleanup Tool UI , which we think is more comprehensible for users.
Launched a sandboxed ESET-Powered Chrome Cleanup Tool
Running on 100% of Chrome users by Nov 23
Lastly, we (BoringSSL) deployed TLS 1.3 to Chrome stable for a couple weeks in December and gathered valuable data.
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.