On Tue, Jun 9, 2015 at 1:17 PM James M. Greene <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 >>> >>>
