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

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

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 26 Jan 2010 20:49:44 +0000
Message-ID: <7789133a1001261249l12c080b1h92ee8dc1d6bc532f@mail.gmail.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
Leonard,

I'm tired of explain this issue to you.  If I remove that line of
code, the Gears plugin will allow the sandboxed content to access the
databases for the non-sandboxed version of the origin.  That is the
proximate security vulnerability.

Adam


On Tue, Jan 26, 2010 at 8:46 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> You are ASSUMING that it is a security vulnerability...hence the reason we can't agree.
>
> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Tuesday, January 26, 2010 8:49 PM
> To: Leonard Rosenthol
> Cc: Maciej Stachowiak; public-html@w3.org
> Subject: Re: What defines a "plugin"? WRT sandboxing?
>
> What line of code ought I to write instead of that one in order to
> avoid introducing a security vulnerability?
>
> Adam
>
>
> On Tue, Jan 26, 2010 at 7:36 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> That code is an implementation on the current PROPOSED text for how sandboxing should work.
>>
>> I am suggesting that there is a BETTER WAY to implement sandboxing with respect to content types.
>>
>> But since you seem to believe that the spec can't be changed - it makes it difficult to discuss.
>>
>> Leonard
>>
>> -----Original Message-----
>> From: Adam Barth [mailto:w3c@adambarth.com]
>> Sent: Tuesday, January 26, 2010 6:07 PM
>> To: Leonard Rosenthol
>> Cc: Maciej Stachowiak; public-html@w3.org
>> Subject: Re: What defines a "plugin"? WRT sandboxing?
>>
>> Regardless of whether my argument is "specious," WebKit needs to
>> include this line of code or else it will contain a security
>> vulnerability:
>>
>> http://trac.webkit.org/browser/trunk/WebCore/loader/FrameLoader.cpp#L1281
>>
>> You can dance around the issue all you like, but those are the facts
>> on the ground.
>>
>> Adam
>>
>>
>> On Tue, Jan 26, 2010 at 4:58 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>>> I completely understand why, today, plugins are an easy scapegoat for what is clearly a larger issue concerning preventing unexpected behavior in a "sandboxed" environment.
>>>
>>> However, you seem to be missing my point.  That the issue is _NOT_ plugins - the issue is the content involved - regardless of where it comes from.
>>>
>>> How many emails you have to send is a specious argument.  We're talking the proper implementation of a technology....
>>>
>>> Leonard
>>>
>>> -----Original Message-----
>>> From: Adam Barth [mailto:w3c@adambarth.com]
>>> Sent: Monday, January 25, 2010 11:22 PM
>>> To: Leonard Rosenthol
>>> Cc: Maciej Stachowiak; public-html@w3.org
>>> Subject: Re: What defines a "plugin"? WRT sandboxing?
>>>
>>> On Mon, Jan 25, 2010 at 9:24 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>>>> What exactly are we trying to prevent?
>>>
>>> We're trying to prevent malicious content from leveraging plug-ins to
>>> escape the security restrictions imposed by @sandbox.  Presently,
>>> there exist a great many plug-ins that do not understand the sandbox
>>> security model and therefore would allow sandboxed content to
>>> circumvent the restrictions of the sandbox.  Therefore, the only safe
>>> course of action is to prevent sandboxed content from interacting with
>>> these plug-ins.
>>>
>>> To answer your specific question, if Safari allowed sandboxed content
>>> to instantiate a QuickTime <video> that circumvented the sandbox
>>> security model, I would email security@apple.com and they would issue
>>> a patch to fix the vulnerability.  If Safari allowed sandboxed content
>>> to instantiate a Gears <object> that circumvented the sandbox security
>>> model, I can either email security@apple.com or security@google.com.
>>> If I email security@apple.com, there's not much they can do except
>>> prevent the content from instantiating Gears.  If I email
>>> security@google.com, there is not much they can do short of preventing
>>> Gears from being used by all content.  Instead of waiting for the
>>> vulnerability to be reported in a shipping product, we're fixing the
>>> vulnerability in the specification by doing what security@apple.com
>>> would have to do anyway.
>>>
>>> Adam
>>>
>>
>
Received on Tuesday, 26 January 2010 20:50:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:13 UTC