Issue metadata
Sign in to add a comment
|
extensions can bypass native messaging origin whitelisting |
||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36
Steps to reproduce the problem:
extension renderers have access to the following IPC handler which is used to launch native messaging host processes:
chromium/src/chrome/browser/renderer_host/chrome_extension_message_filter.cc:88
IPC_MESSAGE_HANDLER(ExtensionHostMsg_OpenChannelToNativeApp,
OnOpenChannelToNativeApp)
On the renderer side, these messages are sent through a JS wrapper that adds the ID of the calling extension to the message:
chromium/src/extensions/renderer/resources/runtime_custom_bindings.js:185
apiFunctions.setHandleRequest('connectNative',
function(nativeAppName) {
var portId = runtimeNatives.OpenChannelToNativeApp(runtime.id,
nativeAppName);
if (portId >= 0)
return messaging.createPort(portId, '');
throw new Error('Error connecting to native app: ' + nativeAppName);
});
This JS function is only registered in extensions with the nativeMessaging permission.
The extension ID sent by the renderer is then passed along in the browser process and used both to determine whether the extension has the nativeMessaging permission and to check whether the extension was whitelisted by the native messaging host in the allowed_origins field of its manifest.
I think that there are two problems here:
- The JS code uses "runtime.id" to determine the current extension's ID, but
the "runtime" object is accessible to the extension and mutable. Therefore,
an extension can change its apparent extension ID using the JS statement
`chrome.runtime.id = "<fake_id>";`.
- If an attacker can execute arbitrary machine code in the context of an extension,
he can send a crafted ExtensionHostMsg_OpenChannelToNativeApp message containing
an arbitrary extension ID to the browser process.
I have built a PoC extension (attached, both as a zipfile and as crx) that clobbers the Chrome Remoting configuration file with garbage. It requires the nativeMessaging permission. Usage:
- (if not done already: set the machine up as a Chrome Remoting host)
- install the extension
- open the extension's options page
- click the "connect to chromoting native messaging host with faked extension ID" button
- view ~/.config/chrome-remote-desktop/host#{hash}.json; all the values in the file
should be overwritten with "CLOBBER"
I suspect that at this point, a malicious extension could overwrite the configuration file with values that allow the attacker to subsequently use Chrome Remoting to access the victim's machine remotely.
What is the expected behavior?
What went wrong?
Did this work before? N/A
Chrome version: 50.0.2661.94 Channel: stable
OS Version:
Flash Version: Shockwave Flash 21.0 r0
,
May 5 2016
,
May 6 2016
Labeling as a high-severity bug. Sounds like the only thing keeping it from being critical is that it requires the victim to have Chrome Remoting set up. Devlin, can you please take a look?
,
May 6 2016
,
May 10 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c7ce4fc66d9d3a2811306edbd9e69f2355efb62c commit c7ce4fc66d9d3a2811306edbd9e69f2355efb62c Author: rdevlin.cronin <rdevlin.cronin@chromium.org> Date: Tue May 10 01:41:37 2016 [Extensions] Clean and update runtime bindings BUG=591164 BUG= 609286 Review-Url: https://codereview.chromium.org/1960903002 Cr-Commit-Position: refs/heads/master@{#392512} [modify] https://crrev.com/c7ce4fc66d9d3a2811306edbd9e69f2355efb62c/extensions/renderer/resources/binding.js [modify] https://crrev.com/c7ce4fc66d9d3a2811306edbd9e69f2355efb62c/extensions/renderer/resources/runtime_custom_bindings.js [modify] https://crrev.com/c7ce4fc66d9d3a2811306edbd9e69f2355efb62c/extensions/renderer/runtime_custom_bindings.cc
,
May 10 2016
Are you going to also add a check on the browser side to ensure that even a malicious renderer process can't open native channels it shouldn't be allowed to open?
,
May 19 2016
rdevlin.cronin: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 23 2016
@6 Yes, I was planning on adding a couple browser-side checks to help out (at least ensure that we aren't just taking whatever id is passed in at face value). Unfortunately, if an attacker has complete control over a renderer process, they can impersonate the extension's (here, Chrome Remoting) background page, and send arbitrary messages. Fundamentally, I don't know if there's anything we can do about that, since the browser would be unable to differentiate the malicious host from the real background page. Luckily, it's very rare to take of a renderer with that level of control.
,
May 24 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71 commit 364adab6eb1e5d928ddd18ed12c9b2a6338c4d71 Author: rdevlin.cronin <rdevlin.cronin@chromium.org> Date: Tue May 24 22:18:29 2016 [Extensions] Determine NativeMessaging ID solely on the browser process No need to trust renderers here. We really should do this in more places. BUG= 609286 Review-Url: https://codereview.chromium.org/2006013002 Cr-Commit-Position: refs/heads/master@{#395708} [modify] https://crrev.com/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71/chrome/browser/extensions/api/messaging/message_service.cc [modify] https://crrev.com/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71/chrome/browser/extensions/api/messaging/message_service.h [modify] https://crrev.com/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71/chrome/browser/renderer_host/chrome_extension_message_filter.cc [modify] https://crrev.com/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71/chrome/browser/renderer_host/chrome_extension_message_filter.h [modify] https://crrev.com/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71/extensions/browser/extension_web_contents_observer.h [modify] https://crrev.com/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71/extensions/common/extension_messages.h [modify] https://crrev.com/364adab6eb1e5d928ddd18ed12c9b2a6338c4d71/extensions/renderer/runtime_custom_bindings.cc
,
May 25 2016
,
May 25 2016
Your change meets the bar and is auto-approved for M52 (branch: 2743)
,
May 26 2016
,
May 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/68f5ddb98b2c2f2be37902941b0a97186dfe7d91 commit 68f5ddb98b2c2f2be37902941b0a97186dfe7d91 Author: Devlin Cronin <rdevlin.cronin@chromium.org> Date: Thu May 26 18:52:23 2016 [Extensions] Determine NativeMessaging ID solely on the browser process No need to trust renderers here. We really should do this in more places. BUG= 609286 Review-Url: https://codereview.chromium.org/2006013002 Cr-Commit-Position: refs/heads/master@{#395708} (cherry picked from commit 364adab6eb1e5d928ddd18ed12c9b2a6338c4d71) Review URL: https://codereview.chromium.org/2014893003 . Cr-Commit-Position: refs/branch-heads/2743@{#85} Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939} [modify] https://crrev.com/68f5ddb98b2c2f2be37902941b0a97186dfe7d91/chrome/browser/extensions/api/messaging/message_service.cc [modify] https://crrev.com/68f5ddb98b2c2f2be37902941b0a97186dfe7d91/chrome/browser/extensions/api/messaging/message_service.h [modify] https://crrev.com/68f5ddb98b2c2f2be37902941b0a97186dfe7d91/chrome/browser/renderer_host/chrome_extension_message_filter.cc [modify] https://crrev.com/68f5ddb98b2c2f2be37902941b0a97186dfe7d91/chrome/browser/renderer_host/chrome_extension_message_filter.h [modify] https://crrev.com/68f5ddb98b2c2f2be37902941b0a97186dfe7d91/extensions/browser/extension_web_contents_observer.h [modify] https://crrev.com/68f5ddb98b2c2f2be37902941b0a97186dfe7d91/extensions/common/extension_messages.h [modify] https://crrev.com/68f5ddb98b2c2f2be37902941b0a97186dfe7d91/extensions/renderer/runtime_custom_bindings.cc
,
Jul 20 2016
,
Sep 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by dcheng@chromium.org
, May 4 2016Owner: rdevlin....@chromium.org