See https://sintonen.fi/advisories/curl-ssh-insufficient-host-identity-verification.txt. cURL upstream dispute that this is a vulnerability, but my view is that it is, given the docs specifically call out SCP. """ Description ----------- Curl can perform SFTP and SCP connections to download from or upload to SSH server. As part of this SSH connection curl validates the host identity against the database of known hosts (.ssh/known_hosts). The curl man page about "--insecure" option says: (TLS SFTP SCP) By default, every secure connection curl makes is verified to be secure before the transfer takes place. This option makes curl skip the verification step and proceed without checking. ... For SFTP and SCP, this option makes curl skip the known_hosts verification. known_hosts is a file normally stored in the user's home directory in the ".ssh" subdirectory, which contains hostnames and their public keys. WARNING: using this option makes the transfer insecure. This documentation implies that by default (if --insecure option is not present), known_hosts verification will be performed, and the transfer is secure. However, due to a logic flaw, curl omits this validation if the .ssh/known_hosts file is missing entirely. When the file is missing curl connection to an SSH host system is vulnerable to attacker in the middle attacks. When using key based authentication, it allows a malicious host to spoof the target host, and either return tampered or otherwise malicious content on download, or for uploads for the attacker to capture the uploads. When using password authentication it will also leak the username and password to the attacker, and thus allows the attacker to connect to the intended target host with the leaked credentials. The ssh/.known_hosts file generally is missing for accounts that have not used ssh commands before. For interactive user accounts this can be considered rare. The situation can happen more often for technical accounts set up for applications or automated processing. It can also easily happen when curl is deployed via docker. For example using dockerized curl like this is vulnerable: $ docker run --rm curlimages/curl:8.11.1 -u bob:hunter2 sftp://target.invalid/file The attack can be performed at any network position between the curl client and the target SSH server. Typical low effort attack scenario would involve running a rogue access point that performs the attack. More advanced exploitation is possible by actors with privileged access to networking equipment. It should be noted that curl project itself doesn't consider this issue a security vulnerability. The project argues that the "Warning: Couldn't find a known_hosts file" message shown should be enough to alert the user to the issue. Additionally, the project argues that the documentation does not explicitly state that the operation would be safe if the known_hosts file is missing. The argument also is that the user should understand that the connection would be insecure under these circumstances. Finally, the project also mentions that this is the way curl has worked for a long time. Curl project also notes that this an area/behavior that could be improved in curl. My remarks on these arguments are: 1. The warning message is enough to warn the users There might not be human reading the warning message if curl is used in automation. Even if there is, this assumes that user understands that despite the message the user credentials have already been leaked, the download might have been replaced with malicious content, or the upload sent to an attacker controlled system. The message is also often hidden among a lot of other information presented (such as the progress bar), so it's rather easy to miss. 2. Documentation doesn't claim curl being secure in this condition This is true, but the documentation of --insecure option explicitly says that: "(TLS SFTP SCP) By default, every secure connection curl makes is verified to be secure before the transfer takes place." This statement is quite explicit in claiming that every TLS, SFTP, SCP connection is secure by default, unless if curl is told to be insecure. While the statement "There is no documentation claiming the opposite" is true, I argue that users can understand the documentation in a way that curl would be secure even if the known_hosts file is missing. 3. Users should understand curl being insecure in this condition Experienced users might understand that something is off if they spot the warning message. However, this assumes quite intimate understanding of SSH protocol and host key validation. In my experience this is not capability many inexperienced users have. Finally, all other SSH tools (including OpenSSH) by default will consider missing known_hosts file same as "the host is not known". 4. Curl has worked like this for a long time Generally, curl project doesn't want to change behavior on a whim, and I agree with this in most situations. Even a small behavioral change can lead to countless of automated tasks suddenly failing. If this long-standing behavior wouldn't lead to security impact this argument would be much stronger. Here I believe that curl should rather outright fail if the known_hosts file is missing. This would be a behavioral change, and it would break some existing workflows. But the affected workflows are vulnerable to Attacker in the Middle attacks, so I believe this is acceptable. I respect the curl project and the team and applaud their excellent security work. However, I can't agree with them about this issue not being a vulnerability. The full discussion about this can be read from the following Hackerone ticket: https://hackerone.com/reports/2961050 """
The advisory has: """ Mitigations ----------- 1. You can apply the following patch to fix the issue: ---8<--- diff --git a/src/tool_operate.c b/src/tool_operate.c index 007a5e054..52e10a5f5 100644 --- a/src/tool_operate.c +++ b/src/tool_operate.c @@ -1170,14 +1170,13 @@ static CURLcode config2setopts(struct GlobalConfig *global, /* new in curl 7.19.6 */ result = res_setopt_str(curl, CURLOPT_SSH_KNOWNHOSTS, known); curl_free(known); - if(result == CURLE_UNKNOWN_OPTION) - /* libssh2 version older than 1.1.1 */ - result = CURLE_OK; - if(result) - return result; } - else + else { warnf(global, "Couldn't find a known_hosts file"); + result = res_setopt_str(curl, CURLOPT_SSH_KNOWNHOSTS, ""); + } + if(result) + return result; } } ---8<--- With this modification curl command will delegate the validation to the whichever SSH backend that has been compiled to curl. Empty filename cannot be opened and will result in the host identity not considered valid. This patch also changes the behaviour if the SSH backend doesn't understand CURLE_UNKNOWN_OPTION option: This is now considered a fatal error. Note that this patch likely won't apply as-is to all curl versions. However, the change should be trivial to backport to other curl releases, too. """ We may want to apply that.
My own suggestion for now is to see how it plays out, whether curl ends up adopting some compromise / change in behaviour (even if they don't consider it a security bug), etc.
(In reply to Sam James from comment #2) > My own suggestion for now is to see how it plays out, whether curl ends up > adopting some compromise / change in behaviour (even if they don't consider > it a security bug), etc. Daniel says there: > Since #16205 the curl tool insists on either a knownhosts file or --insecure. That patch (https://github.com/curl/curl/commit/e1b3d46944890cd2c1e3eef8d75d292ab0411e35) is merged but not yet released.
