This is explicitly allowed in the code:

https://cs.chromium.org/chromium/src/net/base/port_util.cc?l=93&rcl=46a334169f967102881de54282c993a33641e658
// FTP overrides the following restricted ports.
const int kAllowedFtpPorts[] = {
    21,  // ftp data
    22,  // ssh
};

Unlike HTTP, the grammar used by FTP when talking to the server is far more constrained, and as such it's not clear that this would lead to any sort of vulnerability.

Do you have a POC demonstrating a problem?

oh. so this problem is linked to code logic
i have two ideas
1.chrome should block ftp scheme which used in iframe(not_ban.jpg)
but as a result,the request still send,and get response.


2.not all server use http port(80) ,but almost every server use ssh,so attacker could use this to scan the whole local network of victim,get the host list for other attack
that is to say , victim's browser become a proxy of attacker which could get into a local network.

Deleted: not_ban.jpg 5.3 KB

	not_ban.jpg 5.3 KB View Download

Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

and with a hidden iframe which could access to port 22, user could not know what happened. so maybe the best way to solve it is to block the request from iframe which use ftp scheme (only allow ftp scheme in location)

Various lockdowns have been proposed that would limit the use of FTP in the browser (e.g. treating all FTP requests as downloads).

It's not clear to me that you could use this to "scan the whole network", or even any IP except the IP from which the attacking page was served-- have you successfully executed such an attack? I would not expect the value of s.contentWindow.location to be accessible by the attacking page; this would seem like a Same Origin Policy violation.

yes,that is the keypoint you could see in my POC
if the ssh port is open , the location will be 'about:blank' for it is still trying to open the port.
if the ssh port is closed , the location could not be read and my poc catch the Same Origin Policy violation error. so that i will know it is closed.

I cannot reproduce this (it always shows port 22 is open, regardless of whether it is). Looking in the console, I see 

Subresource requests using legacy protocols (like `ftp:`) are blocked. Please deliver web-accessible resources over modern protocols like HTTPS. See https://www.chromestatus.com/feature/5709390967472128 for details.

That page notes that sub-resource requests to FTP have been blocked since Chrome 59.

Do you see that message? On what platform are you able to reproduce this?

I'm so sorry that i forget this attack linked to the timeout setting of your system. so that you may need to set a longer timeout

i test on windows platform
use a script to listen on port 22
here comes the attack.gif and poc.html

Deleted: attack.gif 3.3 MB

	attack.gif 3.3 MB View Download

Deleted: poc.html 697 bytes

poc.html 697 bytes View Download

Can you elaborate on what you mean specifically when you say "timeout setting of your system"?

The video in Comment #8 definitely looks like a bug.

 Issue 757809  shows one way in which this could've happened, but that was fixed in 62.0.3201.0, so it's not clear how this is happening. On my Windows system, I always see that the port is open, even when it isn't.

I can reproduce this in 61.0.3163.91 with browser-side-navigation enabled

  chrome --enable-browser-side-navigation C:\temp\portprobe.html

I cannot reproduce this in 62.0.3202.29, regardless of the state of browser-side-navigation.

oh,i know . i use the stable version to test it.
the iframe issue was fixed in beta version
but the main problem still exists,so i rewrite the POC
online demo https://www.math1as.com/chrome/opener.html

Fair enough, the repro in #11 seems to work in Chrome 63.3221 if the popup is allowed.

(I don't think we do port blocking on iOS, is that right?)

I've reproduced the bug on Chrome OS, version 60, FWIW.

#11: Can you please attach the new repro case to this bug? Thanks!

We don't use Chrome's network stack for web-issued requests on iOS, because the API doesn't let us.  We still use it for our own internal requests, though.

Chrome can probably remove port 22 from kAllowedFtpPorts.

AFAIK port 22 should only have widespread use for SFTP, which Chrome doesn't support.

Sounds safe to remove once we have data to confirm this.

Some quick searches on censys.io show that of the 10,960,217 hosts responded on port 22 [1], only 11,202 included "FTP in their raw banners without also including "SSH" [2]. That's about 0.1%, and I'm not convinced any of these are accessed over the web.

Given that, here's the quick CL for removing port 22 from the list: https://crrev.com/c/860753 

[1] https://censys.io/ipv4?q=protocols.raw%3A+%2222%2Fssh%22
[2] https://censys.io/ipv4?q=22.ssh.v2.banner.raw%3A+%22FTP%22+AND+protocols.raw%3A+%2222%2Fssh%22+AND+not+22.ssh.v2.banner.raw%3A+%22SSH%22

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

commit 112756ed920162dcb74660b0bed57a3f559710c8
Author: Christopher Thompson <cthomp@chromium.org>
Date: Wed Jan 10 23:03:25 2018

Remove port 22 from the set of allowed FTP ports.

The collision with SSH ports caused some possible concerns with being
able to enumerate internal hosts. Analysis shows that Internet hosts
supporting FTP over port 22 are a small fraction, and likely not
accessed over the web.

Bug:  767354 
Change-Id: I8958b4cc818b34127fd739d2dea58f498fb073c0
Reviewed-on: https://chromium-review.googlesource.com/860753
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528461}
[modify] https://crrev.com/112756ed920162dcb74660b0bed57a3f559710c8/net/base/port_util.cc

I'm afraid the VRP panel declined to reward for this report.

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