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

The browser could copy a terminal command to wipe the disk, and the user
could run it. Or copy a URL to a web page that has a known security
exploit, and then the user pastes it in to the address bar. Maybe we
shouldn't allow copying anything at all?

Actually I think this is just security by paranoia. If pasting corrupt
images in to another app is enough of a problem to warrant concern, that
app should be fixed, rather than hobble the browser.
On 9 Jun 2015 21:23, "Daniel Cheng" <dcheng@google.com> wrote:

> On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht <paul@hoplahup.net> wrote:
>
>>  Daniel,
>>
>> this does not make sense to me.
>>
>> All these image parsers exploits can be triggered by an img tag, or?
>> Similarly for XML using an XHR or some particular XML formats (RSS, SVG,
>> XHTML, ...) in markup.
>>
>
> Sure. That's why Chrome only decodes images in sandboxed processes like
> the renderer.
>
>
>>
>> There's absolutely no difference in the mistrust we should have between
>> content brought by an HTML page and content brought by a JavaScript, or?
>> Hence we should just not accept the reason of knowing of broken parsers to
>> be a reason to change the standards!
>>
>
> The difference is that "copy image to clipboard" never writes a
> GIF/JPG/PNG to the clipboard. The trusted browser process grabs the raw
> decoded bitmap from the renderer, validates the size information and some
> other stuff, and then writes it to the clipboard as a bitmap of the
> appropriate format.
>
> On the other hand, supporting this from JS means the untrusted renderer
> would get to control and place arbitrary GIF/JPG/PNG into the clipboard.
> It's not really feasible to do any corresponding validation that the data
> isn't bad.
>
>
>>
>> If, as a president, you need to decide to change the roads because a
>> particular car was built massively and needs a particularirty of your
>> roads, you would also find it nonsense, or? You're making me feel like
>> France which did this for a particular type of trains which required to
>> change all platforms because their ordered trains were already built too
>> wide....
>>
>
> It's unfortunate, but I doubt any native apps attempt to securely decode
> images. Previously, it didn't matter, since the clipboard content came from
> other native apps, and if you can't trust other native apps, you're kind of
> hosed anyway. However, going from web content -> native crosses a security
> boundary, which means these sort of issues need to be taken into
> consideration.
>
>
>
>>
>> Paul
>>
>>
>> On 9/06/15 21:15, Daniel Cheng 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
>>>
>>>
>>