Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: [SECURITY ADVISORY] curl: trusting FTP PASV responses
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_cool.haxx.se>
Date: Wed, 9 Dec 2020 15:54:51 +0100 (CET)
On Wed, 9 Dec 2020, Paul Gilmartin via curl-users wrote:
>> 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.
>>
> Ouch! "unwise" Without qualification? "man curl" says:
I don't understand the question. What "qualification" would there be? You
communicate with a server, the server responds back with further instructions.
What other qualifications could there be for a clear text network protocol?
> Am I at risk with:
> curl --trace-ascii trace ftp://service.boulder.ibm.com/s390/holddata/full.txt
If you run that command on your local machine: If that server is a malicious
one it could return a made up IP adress and port number, but that would just
make your local curl command line act up. It wouldn't be an issue.
If you instead run that command line perhaps on your web server and it shows
the response to the world, then the malicious server could be crafted to make
your service reveal internal server/network information to visitors.
> Is there a remedy?
Isn't this pretty clear in the advisory?
1. curl 7.74.0 has a toggled default behavior and now needs an explicit option
provided for it to trust the returned IP address
2. For earlier versions, you can use --ftp-skip-pasv-ip to make curl ignore
the provided IP address
Date: Wed, 9 Dec 2020 15:54:51 +0100 (CET)
On Wed, 9 Dec 2020, Paul Gilmartin via curl-users wrote:
>> 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.
>>
> Ouch! "unwise" Without qualification? "man curl" says:
I don't understand the question. What "qualification" would there be? You
communicate with a server, the server responds back with further instructions.
What other qualifications could there be for a clear text network protocol?
> Am I at risk with:
> curl --trace-ascii trace ftp://service.boulder.ibm.com/s390/holddata/full.txt
If you run that command on your local machine: If that server is a malicious
one it could return a made up IP adress and port number, but that would just
make your local curl command line act up. It wouldn't be an issue.
If you instead run that command line perhaps on your web server and it shows
the response to the world, then the malicious server could be crafted to make
your service reveal internal server/network information to visitors.
> Is there a remedy?
Isn't this pretty clear in the advisory?
1. curl 7.74.0 has a toggled default behavior and now needs an explicit option
provided for it to trust the returned IP address
2. For earlier versions, you can use --ftp-skip-pasv-ip to make curl ignore
the provided IP address
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ----------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2020-12-09