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" <dch...@google.com> wrote: > On Tue, Jun 9, 2015 at 12:27 PM Paul Libbrecht <p...@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 <o...@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 >>> >>> >>