New issue
Advanced search Search tips

Issue 767354 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug-Security



Sign in to add a comment

Security: Detect open SSH port via FTP protocol

Reported by ma7h1a...@gmail.com, Sep 21 2017

Issue description

AFFECTED PRODUCTS
--------------------
chrome 61.0.3163.91 stable
chrome 62.0.3202.18 beta

DESCRIPTION
--------------------
when access to some reserved port
such as SSH (port 22)
due to security reasons chrome would block it(ban.jpg)

but with some scheme , we could bypass it

so attacker could access to those port of victim and even leak information of local area network

Online Demo: http://www.math1as.com/chrome/unsafe_port.html

connect.jpg show that the application listen on localhost:22 recv a connection of chrome

 
 
ban.jpg
17.2 KB View Download
connect.jpg
6.8 KB View Download
poc.html
668 bytes View Download
Components: Blink>Network
Labels: Needs-Feedback
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?

Comment 2 by ma7h1a...@gmail.com, Sep 21 2017

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.
not_ban.jpg
5.3 KB View Download
Project Member

Comment 3 by sheriffbot@chromium.org, Sep 21 2017

Cc: elawrence@chromium.org
Labels: -Needs-Feedback
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

Comment 4 by ma7h1a...@gmail.com, Sep 21 2017

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)
Summary: Security: Detect open SSH port via FTP protocol (was: Security: unsafe port could be access via crafted html page)
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.

Comment 6 by ma7h1a...@gmail.com, Sep 21 2017

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?

Comment 8 by ma7h1a...@gmail.com, Sep 21 2017

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
attack.gif
3.3 MB View Download
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
Cc: mmenke@chromium.org
Components: Internals>Network>FTP
Status: Untriaged (was: Unconfirmed)
Fair enough, the repro in #11 seems to work in Chrome 63.3221 if the popup is allowed.
Cc: eroman@chromium.org
Cc: pinkerton@chromium.org
Components: Privacy
Labels: Security_Severity-Low Security_Impact-Stable M-63 OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac OS-Windows Pri-2
Status: Available (was: Untriaged)
(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
Project Member

Comment 19 by bugdroid1@chromium.org, Jan 10 2018

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

Status: Fixed (was: Available)
Project Member

Comment 21 by sheriffbot@chromium.org, Jan 11 2018

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: -M-63 M-65
Labels: reward-topanel
Labels: -reward-topanel reward-0
I'm afraid the VRP panel declined to reward for this report.
Labels: Release-0-M65
Labels: CVE-2018-6082
Project Member

Comment 27 by sheriffbot@chromium.org, Apr 19 2018

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
Labels: CVE_description-missing
Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment