Re: Clipboard API: remove dangerous formats from mandatory data types

On Tue, Jun 9, 2015 at 1:17 PM James M. Greene <james.m.greene@gmail.com>
wrote:

> Why we would exclude any data formats that the browsers currently already
> support copying today? Definitely not a fan of that idea offhand.
>
> Is it not possible for a malicious image to be displayed (or display as
> broken) in Chrome and allow a user to choose "Copy Image" from that
> element's context menu?
>
See my earlier reply.

> If not, how is that protection/prevention achieved today? Could the same
> process to applied to outgoing copy/cut operations and incoming paste
> operations?
>
> Sincerely,
>    James M. Greene
>

Incoming paste isn't the problem, it's just outgoing copy/cut.

Can an implementation really claim to support GIF/JPG/PNG if it has to
decode it to a bitmap and then (potentially lossily) convert it back? Image
encoding is not free either; Chrome has a very poor implementation today to
expose image/png, and you'll find if you try to paste a very large bitmap
(several dozen megapixels), the renderer will stop responding for a period
of time.

Daniel


> On Jun 9, 2015 2:19 PM, "Daniel Cheng" <dcheng@google.com> wrote:
>
>> I'm not against considering more formats to be dangerous. =)
>>
>> In particular:
>> JS: I'm not support what context we'd ever want to support this, since we
>> go out of our way to try prevent XSS in HTML pastes.
>> XML: I wouldn't mind getting rid of this. XML parsers seem to have RCE
>> bugs on a semi-regular basis.
>>
>> Daniel
>>
>> On Tue, Jun 9, 2015 at 12:01 PM Olli Pettay <olli@pettay.fi> wrote:
>>
>>> On 06/09/2015 09:39 PM, Daniel Cheng wrote:
>>> > Currently, the Clipboard API [1] mandates support for a number of
>>> formats. Unfortunately, we do not believe it is possible to safely support
>>> writing a
>>> > number of formats to the clipboard:
>>> > - image/png
>>> > - image/jpg, image/jpeg
>>> > - image/gif
>>> >
>>> > If these types are supported, malicious web content can trivially
>>> write a malformed GIF/JPG/PNG to the clipboard and trigger code execution
>>> when
>>> > pasting in a program with a vulnerable image decoder. This provides a
>>> trivial way to bypass the sandbox that web content is usually in.
>>> >
>>> > Given this, I'd like to propose that we remove the above formats from
>>> the list of mandatory data types, and avoid adding support for any more
>>> complex
>>> > formats.
>>> >
>>> > Daniel
>>> >
>>> > [1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1
>>>
>>>
>>> Why would text/html, application/xhtml+xml, image/svg+xml,
>>> application/xml, text/xml, application/javascript
>>> be any safer if the program which the data is pasted to has vulnerable
>>> html/xml/js parsing?
>>>
>>>
>>> -Olli
>>>
>>>