Analysis: Flash Player in a Chrome Sandbox

Wednesday, December 22, 2010

Rafal Los


On December 1st, the Google Chrome development team announced they would support running Adobe Flash in the development releases of Chrome browser. 

This is no doubt an interesting development in the continuing saga of Adobe Flash, but I like to think what it all means in the bigger picture of things.

What does it mean that Google's Chrome will now be running the Flash plug-in inside of a sandbox... and not natively "as-is" in the browser. 

I see this as meaning a few different things, so I'll take a moment to discuss them here and as always you're welcome to discuss or disagree with me. 

I don't think you'll disagree when I say this has far-reaching security implications well beyond the obvious buzz.

Trusting Plug-ins

Google's move says something about the trust for plug-ins.  Mainly, I think it's a logical extension of the conversations that have been going on across the security industry when it comes to browsers and security. 

The result of those conversations is fairly unanimous - whether they're plug-ins, or add-ons, or whatever... they're dangerous. 

Furthermore, browser makers are having a tougher and tougher time exposing the system calls these plug-ins require to function without causing themselves a significant amount of worry of compromise.

So we don't trust plug-ins... so what?  The implications for this are very real when it comes to the HTMLv5 push, and the "no-plugins" movement that's slowly building groundswell support. 

The problems Adobe has had lately keeping itself off the 0-day list week after week doesn't bode well for the trust that browser makers have in the product... and apparently Google Chrome is the first to come out and drop Flash player right into a sandbox. 

Keeping Flash player away from the dangerous OS functions is probably a good thing, but what exactly are those dangerous OS functions? and who gets to make that determination?

I think at the end of the day, what this move by Google's Chrome team is saying is what the IE and FireFox team were already thinking (hopefully)... "We don't trust plug-ins" and we need to figure out how to compartmentalize them so that when they go nuclear, the damage is contained.


Speaking of going nuclear - that seems to be another interesting point that many of the blogs and articles I've read about the move make.  It's not an if but a when the plug-in goes "boom!" the damage can be cushioned, or contained, as best as possible. 

So we as architects of a system are placing less and less trust into 3rd party components that we allow to interact with our platform (software/browser) - which is a good thing, lessons are being learned.  The problem is as we add more of these 3rd party components we keep having to segment out parts of our own system for sandboxes. 

Now if that's done architecturally, that may not be so bad - and honestly I don't know the intimate details of the Chrome sandbox to talk about that intelligently enough - but when I've seen sandboxes implemented in the past it either breaks functionality or boosts resource utilization.  Neither of those are good things.

If the use of a sandbox cripples some feature of a plug-in, then that is one of the fastest ways to guarantee that adoption will fail.  I've said it time and time again, adoption hinges on transparency and ease of use of the security of the system. 

If the only way to make Flash work in Chrome is by breaking functionality and having to cobble together a fix - that won't work.  It doesn't matter how secure the result is, a non-functional system isn't going to be adopted.

Resource bloat is also a problem because as I've personally witnessed in the past, sandboxes can be brutal.  Say you're going to process every JavaScript event in a "sandbox" to make sure it's non-malicious. 

If there are possibly thousands or factors of 10 higher than that on a web application - then you're looking at memory consumption that makes us realize why a browser (ahem, FireFox) can be seen sucking up 700+Mb of memory while running. 

No, these aren't intentional design features, but we all know that what's intended and what actually happens is often drastically different in the real world.

Final Word

The final word on sandboxing?  It's appropriate... sometimes.  If you've got a potentially dangerous plug-in with a proven track-record of being attacked and exploited - and let's face it, Flash does have that - then a sandbox may be the answer. 

A well-constructed, well-constrained, well-defined sandbox may be exactly what a plug-in like Flash needs to function smoothly and cause minimal damage when someone finds the next memory corruption bug, or whatever makes it go boom next. 

But at the same time... does that then help push the drive for the "plug-in-less" HTMLv5 world, where we don't have plug-ins and everything is hacked and exploited using standards?

All I know is, there are still more questions than answers, and we need to look at these things sanely.

Cross-posted from Follow the White Rabbit

Possibly Related Articles:
Adobe Google Plug-Ins sandboxing Chrome
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.