> verify that the Host header is either an IP address or "localhost".

This sounds reasonable to me. 

Given the type of configuration required for exploit, this is probably Severity-Low at best.

> Given the type of configuration required for exploit, this is probably Severity-Low at best.

The only requirement for the user is the --remote-debugging-port flag.
All other steps in the PoC require some work on the attacker's part, but there are no unrealistic assumptions being made there.

The download numbers of Puppeteer (500k+ in the last month alone [1]) shows that there is a significant number of users who can readily be exploited by this, so wouldn't that classify the bug as Medium at least?

[1] https://www.npmjs.com/package/puppeteer

> The only requirement for the user is the --remote-debugging-port flag.

Correct, enabling remote debugging of your browser instance is not a common action and should not be positioned as super-safe.

Enabling remote debugging is a guaranteed action for Puppeteer, a product of Chrome's team which is actively supported and promoted, with multiple use cases that involve loading untrusted web pages.

I added the DevTools label on this bug, will those who work on Puppeteer also see this bug?

Thanks for the report! Setting this to medium per the large user base of puppeteer.

pfeldman, could you please help with this one too? 

pfeldman@, friendly ping. Are you able to have a look at this?

pfeldman: 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

The combination of Puppeteer and DNS spoofing does not sound like "medium". Puppeteer is used for lab testing in the controlled environment and web scraping where users should take measures to protect themselves anyways.

Host: header would sound fine. Puppeteer will eventually move to the pipes instead of http, that would close this topic once and for all.

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

commit ba1513223e47b62ed53b61518b7f7b82ad1d8ccd
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Wed Mar 07 20:14:13 2018

DevTools: check Host header for being IP or localhost when connecting over RDP.

Bug:  813540 
Change-Id: I9338aa2475c15090b8a60729be25502eb866efb7
Reviewed-on: https://chromium-review.googlesource.com/952522
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541547}
[modify] https://crrev.com/ba1513223e47b62ed53b61518b7f7b82ad1d8ccd/content/browser/devtools/devtools_http_handler.cc

pfeldman: 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

 Issue 824816  has been merged into this issue.

Is there any further work to do here, or does the CL in #12 mean that it can be changed to FIXED?

Actually, I'd like to merge it into M66.

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M66. Branch:3359

This attack is effectively public: https://medium.com/0xcc/visual-studio-code-silently-fixed-a-remote-code-execution-vulnerability-8189e85b486b

The conclusion of that article is "Better use an alternative random port than 9333 to avoid potential exploit.".
That doesn't resolve the security issue, it only obscures the problem (and it's not even effective). Just like Chrome, VSC/Electron/Node.js should validate the Host header to avoid exploitation through web browsers.

Since ofrobots@ was CC'd in comment 18, I guess that the Node.js team is aware of this.
Eric: If not, could you reach out to the relevant teams?

Node fix is on its way, VSC/Electron no longer listen to the port by default afaik. They are based on chromium, so they should pick the upstream fix as they roll.

@John: could you check if remote ChromeDriver scenarios are working as expected with this? If you are not sending Host: header in your RDP requests, you should not be affected.

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

commit 0e914b95f7cae6e8238e4e9075f248f801c686e6
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Fri Mar 23 16:43:55 2018

DevTools: check Host header for being IP or localhost when connecting over RDP.

TBR=pfeldman@chromium.org

(cherry picked from commit ba1513223e47b62ed53b61518b7f7b82ad1d8ccd)

Bug:  813540 
Change-Id: I9338aa2475c15090b8a60729be25502eb866efb7
Reviewed-on: https://chromium-review.googlesource.com/952522
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Pavel Feldman <pfeldman@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#541547}
Reviewed-on: https://chromium-review.googlesource.com/978444
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#397}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/0e914b95f7cae6e8238e4e9075f248f801c686e6/content/browser/devtools/devtools_http_handler.cc

@Pavel: ChromeDriver always uses Host header while communicating to DevTools, and there seems to be no easy way to disable it. https://cs.chromium.org/chromium/src/net/http/http_network_transaction.cc?type=cs&q=HttpNetworkTransaction::BuildRequestHeaders unconditionally adds Host header. So we'll have to modify the net library to add a new option.

By the way, how do I tell DevTools to allow remote connections? Even though it's called remote-debugging-port, my testing showed that by default it refuses remote connections.

> ChromeDriver always uses Host header while communicating to DevTools, and there seems to be no easy way to disable it.

RDP is allowed if the host header is missing, "localhost" or an IP address. This probably covers the most significant (if not all) use cases of ChromeDriver, doesn't it?

> So we'll have to modify the net library to add a new option.

If the host restriction is too strict, I would suggest supporting a new flag to whitelist additional hosts (see the end of my bug report) instead of modifying net/.

> how do I tell DevTools to allow remote connections

$ chromium --user-data-dir=/tmp/whatever --remote-debugging-port=9333 &
$ netstat -na |grep 9333
tcp        0      0 127.0.0.1:9333          0.0.0.0:*               LISTEN     

Chrome binds to 0.0.0.0, so it should be remotely accessible. If it does not in your case, check whether your firewall is blocking connections.

>> By the way, how do I tell DevTools to allow remote connections? Even though it's called remote-debugging-port, my testing showed that by default it refuses remote connections.

Could you resolve address to IP first and then establish the RDP connection using that IP address?

>> Could you resolve address to IP first and then establish the RDP connection using that IP address?

I can, but there are complications. Resolving one host name can resulting in multiple IP addresses. It will be an additional complexity in ChromeDriver to explicitly try each IP address. An alternative would be requiring the user to pass in IP address instead of host name for remote connections.

This apparently got filed in 2016 as  Issue 650094 

*** 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.
*********************************

The panel decided to award $500 for this report. Thanks as ever!

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