trusting FTP PASV responses
When curl performs a passive FTP transfer, it first tries the `EPSV` command and if that is not supported, it falls back to using `PASV`. Passive mode is what curl uses by default. A server response to a `PASV` command includes the (IPv4) address and port number for the client to connect back to in order to perform the actual data transfer. This is how the FTP protocol is designed to work. A malicious server can use the `PASV` response to trick curl into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions. If curl operates on a URL provided by a user (which by all means is an unwise setup), a user can exploit that and pass in a URL to a malicious FTP server instance without needing any server breach to perform the attack.
02 / AFFECTED SOFTWARE
Affected packages
174 explicit affected versions
372 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
A malicious server can use the FTP PASV response to trick curl 7.73.0 and earlier into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions.
When curl performs a passive FTP transfer, it first tries the `EPSV` command and if that is not supported, it falls back to using `PASV`. Passive mode is what curl uses by default. A server response to a `PASV` command includes the (IPv4) address and port number for the client to connect back to in order to perform the actual data transfer. This is how the FTP protocol is designed to work. A malicious server can use the `PASV` response to trick curl into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions. If curl operates on a URL provided by a user (which by all means is an unwise setup), a user can exploit that and pass in a URL to a malicious FTP server instance without needing any server breach to perform the attack.
05 / REFERENCES
Further evidence
- https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf
- https://curl.se/docs/CVE-2020-8284.html
- https://hackerone.com/reports/1040166
- https://lists.debian.org/debian-lts-announce/2020/12/msg00029.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DAEHE2S2QLO4AO4MEEYL75NB7SAH5PSL/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NZUVSQHN2ESHMJXNQ2Z7T2EELBB5HJXG/
- https://security.gentoo.org/glsa/202012-14
- https://security.netapp.com/advisory/ntap-20210122-0007/
- https://support.apple.com/kb/HT212325
- https://support.apple.com/kb/HT212326
- https://support.apple.com/kb/HT212327
- https://www.debian.org/security/2021/dsa-4881
- https://www.oracle.com//security-alerts/cpujul2021.html
- https://www.oracle.com/security-alerts/cpuApr2021.html
- https://www.oracle.com/security-alerts/cpuapr2022.html
- https://www.oracle.com/security-alerts/cpujan2022.html