[tbb-dev] Q1 Summary from Chrome Security

[Tom Ritter]

And I'll drop another interesting link from the latest Phrack that
talks about Firefox exploitation:
http://phrack.org/issues/69/14.html#article

-tom

On 4 May 2016 at 21:44, Tom Ritter <tom at ritter.vg> wrote:
> 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.