Improving plug-in security
Monday, June 28, 2010
Bad guys want to install persistent malware on your machine. Once they achieve this, they are free to do a variety of bad things such as steal your banking passwords, abuse your network connection, and rifle through your sensitive files.
Bad guys will install malware via the easiest path available. Traditionally, the easiest attack was to simply get a user to run an untrusted executable. Not all users fall for this. And modern operating systems and e-mail systems make this harder to do and restrict the permissions that the downloads run with -- making it less attractive. Next easiest is to exploit a disclosed vulnerability which is not yet patched by all users. The industry’s response to this is to autoupdate its users with security patches; browsers including Firefox and Chrome have demonstrated success at keeping the majority of their user bases current.
More advanced attacks involve finding undisclosed vulnerabilities in the browser. Despite being harder, there has been a lot of user damage due to exploitation of non-public bugs in browsers. Pleasingly, there’s a trend in modern browsers to integrate sandboxing. IE7 on Vista (and newer combinations) plus Google Chrome already have built-in sandboxes of varying strength. This makes many latent browser bugs incapable of persistently installing malware without a lot of additional effort to find a second bug to break out of the sandbox. Again, attackers favor the easiest attack so the increasing robustness of browsers is causing them to look elsewhere for ways to compromise user machines.
This brings us to the present time. We’re seeing a remarkable swing towards attacks that target pieces of browsing infrastructure such as plug-ins. This may be because browsers are taking the lead on auto-update and sandboxing. Since many plug-ins are ubiquitous, they pose the most significant risk to our user base. To better protect Google Chrome users from the threat of plug-in exploits, we have already announced a couple of initiatives:
- More powerful plug-in controls: Google Chrome now has the ability to disable individual plug-ins (about:plugins) or to operate in a “domain whitelist” mode whereby only trusted domains are permitted to load plug-ins (Options->Content Settings->Plug-ins).
- Autoupdate for Adobe Flash Player: By including Adobe Flash Player -- the most popular plug-in -- with Google Chrome, we can re-use Google Chrome’s powerful autoupdate strategy and minimize the window of risk for patched vulnerabilities.
- Integrated, sandboxed PDF viewing: We have announced an integrated PDF viewer plug-in running inside Google Chrome’s sandbox. This will make it harder for PDF-based vulnerabilities to result in the persistent installation of malware.
- Protection from out-of-date plug-ins: Medium-term, Google Chrome will start refusing to run certain out-of-date plug-ins (and help the user update).
- Warning before running infrequently used plug-ins: Some plug-ins are widely installed but typically not required for today’s Internet experience. For most users, any attempt to instantiate such a plug-in is suspicious and Google Chrome will warn on this condition.
- A next generation plug-in API: “Pepper” makes it easier to sandbox plug-ins.
Posted by Chris Evans, Julien Tinnes, Michal Zalewski; Google Security Team

11 comments:
jasonvaritekfan said...
How fast is Chrome auto-update? I remember when Chrome beta first came out with Flash 10.1 RC 1 and Adobe updated Flash 10.1 RC 1 to RC 2, Chrome was still using the former for a few days.
I like having Flash integrated into Chrome.
June 28, 2010 6:34 PM
Puneet Singh said...
why dun u people integrate silverlite with chrome?
June 28, 2010 11:20 PM
Wes said...
Browser sandboxing is important, IE and Chrome came first, and now Firefox is implementing it too. I'm guessing Apple will come along soon (I'm sure it will be revolutionary =P) too. Great job leading the way, guys!
Would any Chrome dev members care to comment on the recent speed tests that had Chrome placing after both the latest builds of IE9 and Fx Minefield? The browser wars are always changing, but thankfully it is the user that benefits.
June 28, 2010 11:54 PM
Anton said...
Ok, I was perfectly fine without Adobe flash. Why did you installed that sh#t on _my_ system without even asking me? How can I remove/disable that now?
June 29, 2010 12:14 AM
Justin said...
@Wes Apple already has this in safari But on in OSX.
June 29, 2010 12:36 AM
Justin said...
@Anton They told you at the top you can now individually disable plug-ins.
Just go to options>Under the hood>content settings>plug-ins and theres a link in there. Its not in your system either its bundled with chrome. Its not right in your computer like if you installed it manually.
June 29, 2010 12:40 AM
vorg said...
How to disable it? I'm a Flash developer and Chrome constantly overrides Debug version of my Flash Player with standard one :/
June 29, 2010 4:44 AM
Anton said...
@Justin, thanks, found it.
I expected it to see somewhere near the rest of extensions/plugins..
June 29, 2010 4:59 AM
Craig said...
The plugin white/black list is AWESOME. Please add this to the extensions page and allow people to do it per-plugin. :)
June 29, 2010 11:12 AM
サトシ said...
Could someone help me on how to enable the built-in Flash Player and PDF viewer in Chromium 6.0.453.0? I can't see them in the chrome://plugins page... =S
June 30, 2010 6:12 AM
Maxim said...
I hope that when you say Chrome will "refuse to run" outdated plug-ins that there will be some setting or workaround that will allow those who have a particular need to run the outdated plug-ins, and are willing to accept/manage the risk, to do so.
July 2, 2010 12:42 PM
Post a Comment