W3C home > Mailing lists > Public > public-html@w3.org > January 2010

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 24 Jan 2010 11:31:08 -0800
Cc: "public-html@w3.org" <public-html@w3.org>
Message-id: <D93CCECF-68E0-432E-B6D8-48A07F1A4A40@apple.com>
To: Leonard Rosenthol <lrosenth@adobe.com>

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

> 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.

That is indeed how the sandbox attribute works. Scripting is off unless you specifically enable allow-script.

>  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”.

These types of attacks use buffer overflows to get native code execution. Definitely a serious security risk, but not the same threat model as XSS. sandboxed iframes are not an effective defense against buffer overflow bugs.

> 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?

Actually, most UAs ship with image and video decoders that are effectively under their control, for built-in features like <img> and <video>. You are right that buffer overflows in this kind of code are potentially a security risk. Bug, again, it's a different threat than XSS and requires different strategies to mitigate. ASLR, W^X and running some or all of the browser with reduced privileges are examples of mitigation strategies for this attack mode.

Received on Sunday, 24 January 2010 19:31:42 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC