Re: [clipboard] navigator.registerClipboardFormats( ... )

2015-07-24 Thread Daniel Cheng
On Wed, Jul 22, 2015 at 12:27 PM Hallvord Reiar Michaelsen Steen 
hst...@mozilla.com wrote:

 Hi,
 there's an interesting proposal here
 https://github.com/w3c/clipboard-apis/issues/9
 for solving our what about clipboard data from various native
 applications? conundrum. The proposal is to let a page indicate what
 native clipboard identifiers it is interested in handling:

 registerClipboardFormats({
application/vnd.mathsoft.equation+xml:[
 XMCD Format, //Windows handle
 MCD Format, //old Windows handle with the same format
 XMCD_FORMAT, //Linux handle
 com.mathsoft.xml], // OSX handle
application/vnd.mathsoft.equation.meta+xml:[
 Provenance Data, //windows handle
 PROVENANCE_DATA, //Linux handle
 com.mathsoft.pd] // OSX handle
 });
 //returns:
 //{
 //   application/vnd.mathsoft.equation+xml:true,
 //   application/vnd.mathsoft.equation.meta+xml:true
 //}

 And my current understanding of how this work work is
 https://github.com/w3c/clipboard-apis/issues/9#issuecomment-123829662 :

 What happens under the hood here is basically:

 The UA has a registry mapping the supported native clipboard types to the
 MIME types used for the clipboard API. For example, on Windows one of the
 entries is probably 'text/html' - 'CF_HTML'
 When registerClipboardFormat() is called, for each MIME type (key) in the
 dictionary, it will check with the OS if the native clipboard knows about
 each format description on the list.
 The first matching format description the OS has registered (if any) will
 be added to the mapping table

 On reading from the clipboard, all data with the descriptions given in our
 mapping table will be exposed to JS with the corresponding MIME type.

 On writing to the clipboard, all data with a MIME type listed in the
 mapping table will be placed on the clipboard with the corresponding native
 description.

 Right?

 I'm not sure if implementors are happy about this. There's some pushback
 against allowing web contents to write binary data to the clipboard for
 security reasons - if you have vulnerabilities in local software (which is
 of course a when, not an if) an attacker can trick you into pasting some
 exploit payload into the vulnerable software.

 Also, I know that on Windows applications register their clipboard
 formats - how does this work on other platforms? Will the OSX clipboard be
 able to confirm that com.mathsoft.xml is a known type when the relevant
 software is installed?

 Comments welcome here or in the Github issue.
 -Hallvord R.
 editor of https://w3c.github.io/clipboard-apis/


This proposal is very dangerous.

It's not just about the fingerprinting danger discussed in the GitHub
issue. The clipboard is an untyped and unsafe broadcast IPC mechanism. Many
native programs weren't written with the expectation of parsing malformed
data, but exposing this to the web means this assumption won't hold.
DOCX/RTF/PDF are all quite complicated, and common for remote code
execution vulnerabilities to turn up.

In fact, if this proposed API were implemented, web content would be able
to execute arbitrary code even in the absence of a bugs. A Pwn2Own exploit
abused the clipboard to do precisely this:
https://code.google.com/p/chromium/issues/detail?id=352395.

Gating this behind a permission doesn't make this proposal any less
dangerous: the permission may as well be called do anything to your
computer.

Daniel


[clipboard] navigator.registerClipboardFormats( ... )

2015-07-22 Thread Hallvord Reiar Michaelsen Steen
Hi,
there's an interesting proposal here
https://github.com/w3c/clipboard-apis/issues/9
for solving our what about clipboard data from various native
applications? conundrum. The proposal is to let a page indicate what
native clipboard identifiers it is interested in handling:

registerClipboardFormats({
   application/vnd.mathsoft.equation+xml:[
XMCD Format, //Windows handle
MCD Format, //old Windows handle with the same format
XMCD_FORMAT, //Linux handle
com.mathsoft.xml], // OSX handle
   application/vnd.mathsoft.equation.meta+xml:[
Provenance Data, //windows handle
PROVENANCE_DATA, //Linux handle
com.mathsoft.pd] // OSX handle
});
//returns:
//{
//   application/vnd.mathsoft.equation+xml:true,
//   application/vnd.mathsoft.equation.meta+xml:true
//}

And my current understanding of how this work work is
https://github.com/w3c/clipboard-apis/issues/9#issuecomment-123829662 :

What happens under the hood here is basically:

The UA has a registry mapping the supported native clipboard types to the
MIME types used for the clipboard API. For example, on Windows one of the
entries is probably 'text/html' - 'CF_HTML'
When registerClipboardFormat() is called, for each MIME type (key) in the
dictionary, it will check with the OS if the native clipboard knows about
each format description on the list.
The first matching format description the OS has registered (if any) will
be added to the mapping table

On reading from the clipboard, all data with the descriptions given in our
mapping table will be exposed to JS with the corresponding MIME type.

On writing to the clipboard, all data with a MIME type listed in the
mapping table will be placed on the clipboard with the corresponding native
description.

Right?

I'm not sure if implementors are happy about this. There's some pushback
against allowing web contents to write binary data to the clipboard for
security reasons - if you have vulnerabilities in local software (which is
of course a when, not an if) an attacker can trick you into pasting some
exploit payload into the vulnerable software.

Also, I know that on Windows applications register their clipboard
formats - how does this work on other platforms? Will the OSX clipboard be
able to confirm that com.mathsoft.xml is a known type when the relevant
software is installed?

Comments welcome here or in the Github issue.
-Hallvord R.
editor of https://w3c.github.io/clipboard-apis/