[chromium-dev] Q3 Summary from Chrome Security

[Andrew R. Whalley]

Greetings!

Chrome turned 10 in September! Congrats to the team on a decade of making
the web more secure
<https://www.wired.com/story/chrome-decade-making-the-web-more-secure/>.

In the quest to find security bugs, the Bugs-- team incorporated Machine
Learning in ClusterFuzz infrastructure using RNN model
<https://en.wikipedia.org/wiki/Recurrent_neural_network> to improve upon
corpus quality and code coverage. We experimented with improving fuzzing
efficiency by adding instability handling and mutation stats strategies
inside libFuzzer. We added a new Mojo service fuzzer
<https://bugs.chromium.org/p/chromium/issues/detail?id=607649> by extending
the Mojo javascript bindings and found security bugs
<https://bugs.chromium.org/p/chromium/issues/list?can=1&q=mojo_fuzzer+label%3AClusterFuzz+Type%3DBug-Security&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids>.
We also migrated
<https://chromium.googlesource.com/chromium/src/+/master/docs/code_coverage.md>
our fuzzing infrastructure to provide Clang Source-based Code Coverage
<https://clang.llvm.org/docs/SourceBasedCodeCoverage.html> reports and
deprecated Sancov <https://clang.llvm.org/docs/SanitizerCoverage.html>.

The Platform Security team continued to add hardening and checks to
fundamental classes and libraries in base/, and did some of the same work
in PDFium and other parsers and interpreters in Chromium. We also provided
some sandboxing consulting to other teams for their new services including
audio and networking.

Chrome on macOS now has a new sandbox architecture, launched in Chrome 69,
which immediately initializes when a new process executes. This reduces
Chrome’s attack surface and allows better auditing of system resource
access between macOS versions.

Chrome OS Security wrapped up the response to the L1TF vulnerability
<https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html>,
fixes for which enabled shipping Linux apps on Chrome OS without exposing
users to extra risk. Moreover, we received an (almost) full-chain exploit
for Chrome OS <https://bugs.chromium.org/p/chromium/issues/detail?id=884511>
that both validated earlier sandboxing work (like for Shill, Chrome OS’s
connection manager) and also shed light on further hardening work that was
wrapped up in Q3.

Chrome 70 shipped TLS 1.3, although we did have to disable a downgrade
check in this release due to a last-minute incompatibility with some
network devices.

After the excitement enabling Site Isolation by default on desktop platforms
<https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html>
in Q2, the team has been focused on building a form of Site Isolation
suitable for devices that run Android, which have more limited memory and
processing power. We've been fixing Android-specific issues (alongside a
lot of maintenance for the desktop launch), we have started field trials
for isolating a subset of sites, and we are working on ways to add more
sites to isolate at runtime. Separately, we added several more enforcements
to mitigate compromised renderers, to extend the protection beyond Spectre.

Users should expect that the web is safe by default, and they’ll be warned
when there’s an issue. In Chrome 68, we hit a milestone for Chrome security
UX, marking all HTTP sites
<https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/>
as “not secure”. We continued down that path in Chrome 70, showing the “not
secure” string in red
<https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/>
when users enter data on an HTTP page. We began stepping towards removing
Chrome’s positive security indicators so that the default unmarked state is
secure, starting by removing the “Secure” wording
<https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html>
in Chrome 69.

We would like to experiment
<https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ZJxkCJq5zo4/4sSMVZzBAwAJ>
with mixed content autoupgrading to simplify (i.e. improve) the user
experience, and are currently collecting metrics about the impact. We’re
also working to improve Chrome security UX under the hood -- we
launched committed
HTTPS interstitials
<https://docs.google.com/document/d/1rEBpw5V-Nn1UIi8CIFa5ZZvwlR08SkY3CogvWE2UMFs/edit>
on Canary and Dev.

As ever, many thanks to all those in the Chromium community, and our VRP
reporters
<https://www.google.com/about/appsecurity/chrome-rewards/index.html>, who
help make the Web more secure!

Cheers,

Andrew, on behalf of the Chrome security team