On Mon, Aug 10, 2009 at 12:32 AM, PhistucK <[email protected]> wrote:
> Obviously, but since there is a website (what started this thread) and > people do run into issues (Help forums) with such a thing, is a specific > solution for Flash, at least, coming up soon? People getting infected while > using Chrome is... really, really, not optimal. > Oh, agreed. But a sandbox for plugins that removes Adobe's ability to let Flash update itself with security fixes doesn't really solve this problem either (which is what some of the discussion earlier in the thread was about). Right now, as I understand it, this vulnerability affects all browsers, not just Chrome--saying that a plugin vendor is in a better position to fix problems within a plugin isn't meant as a cop-out, it's just a description of where the problem lies. Any sandbox is just one line of defense. The underlying problem is that the current spec for browser plugins (NPAPI) effectively gives a plugin all of the capabilities of an application. Flash, since it's a programming environment in its own right, uses those capabilities to deliver value to users. For example, Gmail uses a small Flash application that improves the user experience for attaching files to email messages--but also depends on Flash's ability to access the file system. A video chat widget written in Flash needs access to the I/O subsystem in order to access the webcam. Acrobat (at least in recent versions) allows embedded Javascript, which expands the capabilities of Acrobat but also provides new places for potentially malicious code to live. The fact that these capabilities are used for genuinely useful stuff as well as security exploits is what makes sandboxing plugins difficult. We could turn off file system access, but then all sorts of "file upload" widgets would break, as well as Flash's own update facility. We could turn off access to other I/O devices, but then webcam and video chat would break. The real solution is to improve the plugin runtime environment so that plugins don't need to talk to the OS directly for these sorts of things. There is active work going on in places like the HTML5 working group, Mozilla's plugin wiki and mailing lists, etc. to make this happen, and we're contributing to that work. All of us, browser and plugin writers alike, are painfully aware of the problems here. And while we don't have a spot fix for this particular malicious website, it does serve as a good example of why that work is necessary. --Amanda --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
