Q4 Summary from Chrome Security
Parisa Tabriz
Hello from the Chrome Security Team!
For those that don’t know us already, we do stuff to help make Chrome the most secure platform to browse the Internet. Here’s a recap of some work from last quarter:
The Bugs-- effort aims to find (and exterminate) security bugs. Last quarter, we incorporated more coverage data into our ClusterFuzz dashboard, especially for Android. With this, we hope to optimize our test cases and improve fuzzing efficiency. We also incorporated 5 new fuzzers from the external research community as part of the fuzzer reward program. This has resulted in 33 new security vulnerabilities. Finally, we wrote a multi-threaded test case minimizer from scratch based on delta debugging (a long-standing request from blink devs!) which produces clean, small, reproducible test cases. In reward program news, we've paid over $1.6 million for externally reported Chrome bugs since 2010 ($4 million total across Google). In 2014, over 50% of reward program bugs were found and fixed before they hit the stable channel, protecting our main user population. Oh, and in case you didn’t notice, the rewards we’re paying out for vulnerabilities went up again.
Bugs still happen, so our Guts effort builds in multiple layers of defense. We’re most excited about progress toward a tighter sandbox for Chrome on Android (via seccomp-bpf), which required landing seccomp-bpf support in Android and enabling TSYNC on all Chrome OS and Nexus kernels. We’ve continued to improve our Linux / Chrome OS sandboxing by (1) adding full cross-process interaction restrictions at the BPF sandbox level, (2) making API improvements and some code refactoring of //sandbox/linux, and (3) implementing a more powerful policy system for the GPU sandbox.
After ~2 years of work on Site Isolation, we’re happy to announce that out-of-process iframes are working well enough that some Chrome features have started updating to support them! These include autofill (done), accessibility (nearly done), <webview> (prototyping), devtools, and extensions. We know how complex a rollout this will be, and we’re ready with testing infrastructure and FYI bots. As we announced at our recent Site Isolation Summit (video, slides), our goal for Q1 is to finish up OOPIF support with the help of all of Chrome.
Not all security problems can be solved in Chrome’s Guts, so we work on making security more user-friendly too. For the past few months, we’ve been looking deeper into the causes of SSL errors by looking at UMA stats and monitoring user help forums. One source of SSL errors is system clocks with the wrong time, so we landed a more informative error message in Chrome 40 to let users know they need to fix their clock. We’ve also started working on a warning interstitial for captive portals to distinguish those SSL errors from the rest. Finally, we proposed a plan for browsers to migrate their user interface from marking insecure origins (i.e. HTTP) as explicitly insecure; the initial discussion and external attention has been generally positive.
Over the past few years, we’ve worked on a bunch of isolated projects to push security on the Open Web Platform forward and make it possible for developers to write more secure apps. We recognized we can move faster if we get some of the team fully dedicated to this work, so we formed a new group that will focus on web platform efforts.
As usual, for more thrilling security updates and feisty rants, subscribe to securi...@chromium.org.
To a safer web in 2015!
Parisa, on behalf of Chrome Security