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

Daniel,

I understand now that the mistrust is about parsers that are even
further and I understand it's an added risk.

So the solution is to require that browsers that make known media-types
in the clipboard actually parse it for its value? That sounds doable
(and probably even useful: e.g. put other picture flavours in case of a
pictures).

Paul


On 9/06/15 22:20, Daniel Cheng wrote:
> On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht <paul@hoplahup.net
> <mailto: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
>>     <mailto: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
>>
>