RE: What defines a "plugin"? WRT sandboxing?

Isn't the execution model for scripting, for ANY format - be it HTML, PDF, SVG, SMIL, etc. based on a specific IMPLEMENATION of the language (and associated DOMs)?  I wouldn't assume (or expect) that scripting in Safari is 100% identical to scripting in FF (or Opera or IE).   They each have quite different implementations of JavaScript/ECMAScript thus meaning that any one of these could have "unpredictable security consequences".   So under your philosophy, we should turn off ALL SCRIPTING by default and only allow it when the author opts-in for it.  And I'd be OK with that - because, again, it's consistent between implementations.

Also, scripting is NOT the only attack vector currently being used by in the wild today.  Malformed data (especially of compressed data streams) was quite popular in 2009. Many of the attacks that were used against common plugins would also be possible with HTML UAs.  I am sure that if someone wanted to, it would be possible to construct a PNG image using one of the discovered Flate flaws that would produce "unpredictable security consequences".

There seems to be a HUGE ASSUMPTION by UA vendors that their implementations are "safe from attack" because they can control all the parts (eg. No plugins).  But the fact is that, as you noted, you don't control them all.  Image formats, video codecs, etc. are all things that you "link to" and that you don't have any more control over than you do a plugin. In fact, for some implementations the UA may not even have source code for the technology (eg. relying on the OS it is running on).   So it really is no different than calling on a plugin, is it?

From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Sunday, January 24, 2010 7:20 PM
To: Leonard Rosenthol
Cc: public-html@w3.org
Subject: Re: What defines a "plugin"? WRT sandboxing?


On Jan 24, 2010, at 10:12 AM, Leonard Rosenthol wrote:


If I understand what you are saying, then it also means that your internal support for ANY format - whether it be specifically listed in the HTML5 spec or not AND whether it is implemented via plugin or not - would need to be covered by the sandbox rules.   That seems completely valid and logical (and consistent).

In that case, I would argue that plugins NOT EVEN BE MENTIONED in the sandbox specification - and that instead, the general rules for sandboxing (scripting, external refs, etc.) be applied to the content regardless of how that content is displayed.

If that was the design, we'd probably never allow any plugins. Mixing a different execution model, even if the author has chosen to allow script, is something that can have unpredictable security consequences, so we would not do it without specific opt-in. So you're not going to see allow-script enabling Java for example, and it certainly wouldn't make sense to run any plugin that runs some form of code when allow-script is not set.



So in Safari's case, if someone references QuickTime and they are allowing external references, then it would be OK for you to use it.  OR if your PDF viewer DID support scripting AND the sandbox rule was allow scripting, then it would be OK for you to view it, otherwise it would not.

The rule for plugins then simply become whether the UA can establish whether the plugin is able to adhere to the requirement(s) for that sandbox. If it can, then it runs - if it cannot, then it can't.  BUT explicit disabling of plugins should not be an option!

The option should be to explicitly enable them back, after being disabled by sandbox. And then only if they can follow the rules. The use cases for this require predictable attack surface and strong guarantees of what can and can't be done more than they require availability of a wide range of features.

Regards,
Maciej