curl: CVE-2021-22924: Bad connection reuse due to flawed path name checks

Summary:

Curl_ssl_config_matches attempts to compare whether two SSL connections have identical SSL security options or not. The idea is to avoid reusing a connection that uses less secure, or completely different security options such as capath, cainfo or certificate/issuer pinning.

Unfortunately this function has several flaws in it:

1. It completely fails to take into account “BLOB” type certificate values, such as set by CURLOPT_CAINFO_BLOB and CURLOPT_ISSUERCERT_BLOB. If the application can be made to initiate connection to a user specified location (where these BLOB options are not used) before the “more secure” connection using these options is made, the attacker can point the application to connect to the same address and port, effectively poisoning the connection cache with a connection that has been established with different cainfo or issuecert settings. This leads to attacker being able to neutralize these options and make libcurl ignore them for the connections for which they’re set. I have no obvious CWE number for this one, but CWE-664 Improper Control of a Resource Through its Lifetime might fit.
2. CURLOPT_ISSUERCERT value is not matched. Similar to above.
3. Similarly, the function has an implementation flaw where path names use case-insensitive comparison for capath, cainfo and pinned public key paths. This can lead to a situation where if the attacker can specify the capath, cainfo or pinned public key name that have a different path capitalization. Again, if the attacker can specify some of these values for the connection that is performed before the later supposedly secure connection is made, the attacker is able to make the further connection use incorrect capath, cainfo or pinned public key. This is CWE-41 Improper Resolution of Path Equivalence.
4. Finally, the pinned public key fingerprint set by CURLOPT_PINNEDPUBLICKEY sha256// is incorrectly compared as case-insenstive value. If the attacker is able to create a otherwise valid certificate that has a fingerprint that has the same fingerprint string but with different capitalization (very difficult to pull off in practice), and the application could be tricked to use this value for CURLOPT_PINNEDPUBLICKEY and create a connection, later connection could be confused to think that the pinned public key is the same one.

Exploiting any of these issues requires a situation where the attacker can coax the application to create a TLS connection to the same host and port that will be performed by the application itself later on (for example some backend connection or other high security connection the attacker wishes to man in the middle). In these situations the existing connection with less security guarantees may be reused, allowing man in the middle attacks against the later supposedly secure connection, resulting in loss of confidentiality and integrity. Since this requires an active attack it can’t be thought to have direct availability impact. In most cases where this would result in exploitation would be scenarios where there would be a privilege barrier between the user providing the connection target addresses (lower priority) and the libcurl using application performing the actual connections (higher priority). It can also be exploitable in a scenario where the attacker will try to man in the middle connections performed by other users of the same service (lateral attack towards users at the same privilege level).

Exploiting the first two issues is plausible in a situation where the attacker can obtain a valid certificate for the host, but from issuer that doesn’t match what the application pinning will check for. If the app uses the blob variants to set up pinning and the attacker is able to obtain a certificate for the specific host from for example Let’s Encrypt, the “pin stripping” attack would be plausible.

Exploiting the 3rd issue is be possible in a situation where the attacker can write to a location that has the same path but with a different capitalization. One example of such situation would be an application that uses a /tmp, /dev/shm or similar sticky world writable location to store the capath/cainfo/pinned public key file. The attacker would then be able to use the same location but with different file name capitalization to fool the application to reuse the existing connection for later connections that actually would use a different capath, cainfo or pinned public key. This attack requires that the attacker can provide the options for capath, cainfo or the public cert pinning somehow (the application would need to enable this as part of its normal functionality).

Steps To Reproduce:

This proof of concept demonstrates the 3rd issue with the curl tool:

1. cp /etc/ssl/certs/ca-certificates.crt ca.crt
2. touch CA.crt
3. curl --capath /dev/null --cacert $PWD/ca.crt https://curl.se --next --capath /dev/null --cacert $PWD/CA.crt https://curl.se

If Curl_ssl_config_matches comparison is implemented correctly the 2nd connection should fail.

Proposed Fix:

In Curl_ssl_config_matches:

• Add “blob” binary matching for CURLOPT_CAINFO_BLOB and CURLOPT_ISSUERCERT_BLOB
• Add case-sensitive matching for CURLOPT_ISSUERCERT value
• Use case-sensitive matching for paths and public key cert signature(s)
• Ensure that there are no other SSL parameters that are improperly compared or omitted from the equivalence check

Impact

TLS man in the middle