New issue
Advanced search Search tips

Issue 805224 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 3
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Security



Sign in to add a comment

Security: chrome.debugger can attach to any target

Project Member Reported by rob@robwu.nl, Jan 24 2018

Issue description

VULNERABILITY DETAILS
The chrome.debugger API is only supposed to attach to targets for which the extension has scripting access. This is enforced in the chrome.debugger.attach method.

The chrome.debugger API seems to use the latest protocol version (even though the only supported versions are 1.0, 1.1 and 1.2 according to DevToolsAgentHost::IsSupportedProtocolVersion [1]).

With the latest protocol version, extensions can attach to any target with the Target.attachToTarget message, and effectively bypass the validation. As a result, extensions can automatically debug any page.


VERSION
Chrome Version: 63.0.3239.132 (stable), 66.0.3330.0 (canary)

REPRODUCTION CASE
Install the attached extension and observe an alert dialog at chrome://version.
The impact is serve: program execution using  bug 798222 , and even if that bug is fixed, local file access by flipping the "Allow access to file URLs" flag at chrome://extensions, or any other powerful feature via chrome://flags.


SUGGESTED FIX
At the very least, the Target DevTools domain should be disabled.

But I think that the latest protocol version is too powerful and not designed for extension usage in mind, so until the protocol has undergone a security audit, I suggest to enforce that the messages in the chrome.debugger API must match the requested protocol version (1.2 or lower).



[1] https://chromium.googlesource.com/chromium/src/+/5bb32276369f855317b3fd647670f6ccf905a27a/content/browser/devtools/devtools_agent_host_impl.cc#86
 
debugger-target-bypass.zip
1.3 KB Download
Components: -Platform>Extensions Platform>Extensions>API
Labels: Security_Impact-Stable FoundIn-63
Nice find, thanks!

Comment 2 by mea...@chromium.org, Jan 24 2018

Labels: Security_Severity-Medium
Owner: dgozman@chromium.org
Status: Assigned (was: Untriaged)

Comment 3 by rob@robwu.nl, Jan 24 2018

I have audited the DevTools protocol today, and looked for privilege escalation in extensions (local file access and privileged code execution), and reported  bug 805445  and bug 805557 .

Given the usefulness of the DevTools protocol, I retract my second suggestion (restricting the DevTools protocol to <=1.2) and recommend to modify the chrome.debugger API to enforce the existing target checks on all methods in the "Target.*" DevTools domain.

This could be an extensions/-only change (validating messages in chrome/browser/extensions/api/debugger/debugger_api.cc).
This may also involve changes the DevTools backend (e.g. adding logic to enforce that clients can only access certain web origins/schemes or processes).
Project Member

Comment 4 by sheriffbot@chromium.org, Jan 26 2018

Labels: M-64
Project Member

Comment 5 by sheriffbot@chromium.org, Jan 26 2018

Labels: Pri-1
Project Member

Comment 6 by sheriffbot@chromium.org, Feb 7 2018

dgozman: 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
Project Member

Comment 7 by sheriffbot@chromium.org, Feb 22 2018

dgozman: Uh oh! This issue still open and hasn't been updated in the last 29 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
Project Member

Comment 8 by sheriffbot@chromium.org, Mar 7 2018

Labels: -M-64 M-65

Comment 9 by mmoroz@chromium.org, Mar 30 2018

Friendly ping from the security sheriff. Can we get any update on this?
Status: Started (was: Assigned)
Now that we have a mechanism of restricted clients in place, this should be easy to fix.
Project Member

Comment 11 by bugdroid1@chromium.org, Apr 2

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/46f5cfb6414c04b65cba4ec59ca992f338934fc9

commit 46f5cfb6414c04b65cba4ec59ca992f338934fc9
Author: Dmitry Gozman <dgozman@chromium.org>
Date: Mon Apr 02 19:55:26 2018

[DevTools] Do not create target handler for restricted sessions

Bug:  805224 
Change-Id: I08528e44e79d0a097cfe72ab4949dda538efd098
Reviewed-on: https://chromium-review.googlesource.com/988695
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547496}
[modify] https://crrev.com/46f5cfb6414c04b65cba4ec59ca992f338934fc9/content/browser/devtools/render_frame_devtools_agent_host.cc

Status: Fixed (was: Started)
This should be fixed now.
Project Member

Comment 13 by sheriffbot@chromium.org, Apr 4

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-2000
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************
And $2,000 for this report, thanks as ever!
Labels: -reward-unpaid reward-inprocess
Labels: Release-0-M67
Labels: CVE-2018-6139 CVE_description-missing
Project Member

Comment 20 by sheriffbot@chromium.org, Jul 11

Labels: -Restrict-View-SecurityNotify allpublic
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

Sign in to add a comment