Saturday, January 28, 2012

The dirty secret of browser security #1

Here's a curiousity that's developing in modern browser security: The security of a given browser is dominated by how much effort it puts into other peoples' problems.

This may sound absurd at first but we're heading towards a world where the main browsers will have (with a few notable exceptions):
  • Rapid autoupdate to fix security issues.

  • Some form of sandboxing.

  • A long history of fuzzing and security research.
These factors, combined with an ever more balanced distribution of browser usage, are making it uneconomical for mass malware to go after the browsers themselves.

Enter plug-ins

Plug-ins are an attractive target because some of them have drastically more market share than even the most popular browser. And a lot of plug-ins haven't received the same security attention that browsers have over the past years.

The traditional view in security is to look after your own house and let others look after theirs. But is this conscionable in a world where -- as a browser vendor -- you have the power to defend users from other peoples' bugs?

As a robust illustrative point, a lot of security professionals recently noticed some interesting exploit kit data, showing a big difference in exploitation success between Chrome (~0%) and IE / Firefox (~15%).

The particular exploits successfully targeted are largely old, fixed plug-in bugs in Java, Flash and Reader. So why the big difference between browsers?

The answer is largely the investment Chrome's security team has made in defending against other peoples' problems, with initiatives such as:
  • Blocking out-of-date plug-ins by default and encouraging the user to update.

  • Blocking lesser-used plug-ins (such as Java, RealPlayer, Shockwave etc). by default.

  • Having the Flash plug-in bundled such that it is autoupdated using Chrome's fast autoupdate strategy (this is why Chrome probably has the best Flash security story).

  • The inclusion of a lightweight and reasonably sandboxed default PDF viewer (not all sandboxes are created equal!)

  • The Open Type Sanitizer, which defends against a subset of Windows kernel bugs and Freetype bugs. Chrome often autoupdates OTS faster than e.g. Microsoft / Apple / Linux vendors fix the underlying bug.

  • Certificate public key pinning. This new technology defends against the generally gnarly SSL Certificate Authority problem, and caught a serious CA compromise being abused in Iran last year.
In conclusion, some of the biggest browser security wins over the past couple of years have come from browser vendors defending against other peoples' problems. So I repeat the hypothesis:

The security of a given browser is dominated by how much effort it puts into other peoples' problems

Funny world we live in.

3 comments:

Anonymous said...

Firefox is going to have its own integrated pdf viewer solution - hopefully very soon:
https://github.com/mozilla/pdf.js
https://github.com/mozilla/pdf.js/issues/970

Anonymous said...

Kurt Seifried here, posting anon because I'm not at home. Plugin security is definitely the Achilles heel (well, tendon technically speaking) of browser security. I covered this back in December 2010 http://www.linux-magazine.com/w3/issue/121/048-049_kurt.pdf.

Anonymous said...

firefox + noscript :)