UserAgent: Mozilla/5.0 (X11; CrOS x86_64 7834.70.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

Steps to reproduce the problem:
1. (Set up Chrome Remoting.)
2. Open the Chrome Remote Desktop app, inspect its main.html view, set a breakpoint in sources->(no domain)->extensions::messaging, on the last line of PortImpl.prototype.postMessage.
3. Click on the "share" button under "Remote Assistance".
4. Keep the app blocked on the breakpoint. Grab `this.portId_` in the debugger.

Now, in another window:
5. navigate to a normal webpage.
6. In the devtools console, enter "chrome.runtime" and press enter.
7. Open sources->(no domain)->extensions::messaging and set a breakpoint on the last line of PortImpl.prototype.postMessage.
8. Run `chrome.runtime.sendMessage('a','a')`. This should hit the breakpoint.
9. Run `messagingNatives.PortAddRef(<portid>)`, where <portid> is the portId_ value from the Chrome Remote Desktop app.
10. In a terminal, find the PID of the remote-assistance-host binary with `ps aux|grep remote-assistance-host`, then use `strace -f -p<pid>` to monitor its syscalls.
11. Back in the webpage's devtools, run `messagingNatives.PostMessage(<portid>, '{"evil":true}')`.

What is the expected behavior?

What went wrong?
In strace, you'll see something like this (between a bunch of other things):

[pid 16377] read(9, "{\"evil\":true}", 13) = 13

This shows that the message sent by the unprivileged website's renderer has reached the native messaging host binary. Using crafted messages, I think it should be possible to exploit this to gain full remote access to a machine on which Chrome Remoting is set up and the Chrome Remoting app is open.

The PoC instructions obviously use privileged JS code that the website shouldn't be able to reach. However, note that:

 - While it was necessary to use privileged JS helpers here, those privileged
   helpers still run in the renderer process. An attacker who has managed to
   execute arbitrary native code in the sandboxed renderer process could use
   this to break out of the sandbox.
 - There seems to be no mechanism to avoid collisions of Port IDs. As soon as
   the global 31-bit-counter g_next_channel_id wraps around, port ID collisions
   should occur. Because the browser process keeps no state for Port IDs, I think
   that new ports that collide with old ones would become identical with them,
   allowing an attacker who just needs to be able to run JS code for a sufficient
   amount of time to then send fake messages to things like Chrome Remoting
   native messaging host binaries in the background. However, according to a
   short test I ran, "a sufficient amount of time" seems to be 7 days in this case.

Did this work before? N/A 

Chrome version: 50.0.2661.94  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 21.0 r0