[tbb-dev] Fwd: Q1 Summary from Chrome Security

[Tom Ritter]

This quarterly newsletter that Chrome puts out is pretty cool.
There's some new Windows 10 security features I hope Mozilla is
investigating!


---------- Forwarded message ----------
From: Parisa Tabriz <parisa at chromium.org>
Date: 3 May 2016 at 19:27
Subject: Q1 Summary from Chrome Security
To: Chromium-dev <chromium-dev at chromium.org>, security-dev
<security-dev at chromium.org>
Cc: "security at chromium.org" <security at chromium.org>,
"security-notify at chromium.org" <security-notify at chromium.org>


Greetings web fans,


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. On the
fuzzing front, we’ve continued to improve the integration between
libFuzzer and ClusterFuzz, which allows coverage-guided testing on a
per-function basis. With the help of many developers across several
teams, we’ve expanded our collection of fuzzing targets in Chromium
(that use libFuzzer) to 70! Not all bugs can be found by fuzzing, so
we invest effort in targeted code audits too. We wrote a guest post on
the Project Zero blog describing one of the more interesting
vulnerabilities we discovered. Since we find a lot of bugs, we also
want to make them easier to manage. We’ve updated our Sheriffbot tool
to simplify the addition of new rules and expanded it to help manage
functional bugs in addition just security issues. We’ve also automated
assigning security severity recommendations. Finally, we continue to
run our vulnerability reward program to recognize bugs discovered from
researchers outside of the team. As of M50, we’ve paid out over $2.5
million since the start of the reward program, including over $500,000
in 2015. Our median payment amount for 2015 was $3,000 (up from $2,000
for 2014), and we want to see that increase again this year!


Bugs still happen, so our Guts effort builds in multiple layers of
defense.  On Android, our seccomp-bpf experiment has been running on
the Dev channel and will advance to the Stable and Beta channels with
M50.


Chrome on Windows is evolving rapidly in step with the operating
system. We shipped four new layers of defense in depth to take
advantage of the latest capabilities in Windows 10, some of which
patch vulnerabilities found by our own research and feedback!  There
was great media attention when these changes landed, from Ars Technica
to a Risky Business podcast, which said: “There have been some
engineering changes to Chrome on Windows 10 which look pretty good. …
It’s definitely the go-to browser, when it comes to not getting owned
on the internet. And it’s a great example of Google pushing the state
of the art in operating systems.”


For our Site Isolation effort, we have expanded our on-going launch
trial of --isolate-extensions to include 50% of both Dev Channel and
Canary Channel users!  This mode uses out-of-process iframes (OOPIFs)
to keep dangerous web content out of extension processes. (See here
for how to try it.) We've fixed many launch blocking bugs, and
improved support for navigation, input events, hit testing, and
security features like CSP and mixed content.  We improved our test
coverage and made progress on updating features like fullscreen, zoom,
and find-in-page to work with OOPIFs. We're also excited to see
progress on other potential uses of OOPIFs, including the <webview>
tag and an experimental "top document isolation" mode.


We spend time building security features that people see. In response
to user feedback, we’ve replaced the old full screen prompt with a
new, lighter weight ephemeral message in M50 across Windows and Linux.
We launched a few bug fixes and updates to the Security panel, which
we continue to iterate on and support in an effort to drive forward
HTTPS adoption. We also continued our work on removing powerful
features on insecure origins (e.g. geolocation).


We’re working on preventing abuse of powerful features on the web. We
continue to support great “permissions request” UX, and have started
reaching out to top websites to directly help them improve how they
request permissions for powerful APIs. To give top-level websites more
control over how iframes use permissions, we started external
discussions about a new Permission Delegation API. We also extended
our vulnerability rewards program to support Safe Browsing reports, in
a first program of its kind.


Beyond the browser, our web platform efforts foster cross-vendor
cooperation on developer-facing security features.  We now have an
implementation of Suborigins behind a flag, and have been
experimenting with Google developers on usage. We polished up the
Referrer Policy spec, refined its integration with ServiceWorker and
Fetch, and shipped the `referrerpolicy` attribute from that document.
We're excited about the potential of new CSP expressions like
'unsafe-dynamic', which will ship in Chrome 52 (and is experimentally
deployed on our shiny new bug tracker). In that same release, we
finally shipped SameSite cookies, which we hope will help prevent
CSRF. Lastly, we're working to pay down some technical debt by
refactoring our Mixed Content implementation and X-Frame-Options to
work in an OOPIF world.


We see migration to HTTPS as foundational to any security whatsoever
(and we're not the only ones), so we're actively working to drive
#MOARTLS across Google and the Internet at large. We worked with a
number of teams across Google to help publish an HTTPS Report Card,
which aims to hold Google and other top sites accountable, as well as
encourage others to encrypt the web. In addition to #MOARTLS, we want
to ensure more secure TLS. We mentioned we were working on it last
time, but RC4 support is dead! The insecure TLS version fallback is
also gone. With help from the libFuzzer folks, we got much better
fuzzing coverage on BoringSSL, which resulted in CVE-2016-0705. We
ended up adding a "fuzzer mode" to the SSL stack to help the fuzzer
get past cryptographic invariants in the handshake, which smoked out
some minor (memory leak) bugs. Last, but not least, we rewrote a large
chunk of BoringSSL's ASN.1 parsing with a simpler and more
standards-compliant stack.


Until next time...

Happy Hacking,

Parisa, on behalf of Chrome Security

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

--
You received this message because you are subscribed to the Google
Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to security-dev+unsubscribe at chromium.org.