CVE-2021-22926: CURLOPT_SSLCERT mixup with Secure Transport

How it was found

Summary:

libcurl Secure Transport SSL backend fails to secure the CURLOPT_SSLCERT against current directory file overriding the keychain nickname specified.

This leads to the possibility of locally created file overriding the CURLOPT_SSLCERT specified certificate and thus causing denial of service.

Steps To Reproduce:

1. Configure and build curl against Secure Transport: configure --with-secure-transport && make
2. Have keychain with client certificate called "testcert"
3. Use testcert from keychain to authenticate: ./src/curl -E testcert https://testsite
4. In current directory execute touch testcert
5. Try authenticating again ./src/curl -E testcert https://testsite

curl: (58) SSL: Can't load the certificate "testcert" and its private key: OSStatus -50

The issue stems from the fact that Secure Transport backend code doesn't seem to prefer the keychain over the local file. The documentation says that local file should be prefixed with "./" when used, but the code doesn't have any such checks. Interestingly NSS SSL backend does have the check: https://github.com/curl/curl/blob/master/lib/vtls/nss.c#L432

The impact of this vulnerability is rather limited: In practice it seems to be only usable in causing denial of service against applications using keychain client certificates. It could happen in practice for example if executing command in /tmp directory structure or home directory of another user. The user would be able to prevent the app from creating an authenticated connection by creating a file with matching name used for the keychain nickname used by the app.

Impact

Denial of service