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

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