hnolz.blogg.se - Axway secure transport vulnerabilities

THE SOLUTIONįile names used in this option must contain at least one slash.ī - Apply the patch to your local versionĬ - Do now run your application in directories where other users can inject files.

Affected versions: curl 7.33.0 to and including 7.77.0Īlso note that libcurl is used by many applications, and not always advertised as such.

Using libcurl on macOS built to use Secure Transport. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2021-22926 to this issue. The fixed libcurl version will now instead first check for a certificate in the key chain using the specified name and only if one does not exist, it will check for a file name. This flaw has existed in curl since commit d2fe616e7e in libcurl 7.33.0, released on October 14, 2013. We are not aware of any exploit of this flaw. If the appliction runs with a current working directory that is writable by other users (like /tmp), a malicious user can create a file name with the same name as the app wants to use by name, and thereby trick the application to use the file based cert instead of the one referred to by name making libcurl send the wrong client certificate in the TLS connection handshake. If the name exists as a file, it will be used instead of by name. When libcurl is built to use the macOS native TLS library Secure Transport, an application can ask for the client certificate by name or with a file name - using the same option. This is done with the CURLOPT_SSLCERT option ( -cert with the command line tool). Libcurl-using applications can ask for a specific client certificate to be used in a transfer.

Project curl Security Advisory, July 21st 2021 - VULNERABILITY

Vulnerabilities Table CURLOPT_SSLCERT mixup with Secure Transport