Curl upstream reported an issue (similar to CVE-2013-4545) related to the verification of the connection host name against the server name specified in a TLS/SSL server certificate. When libcurl was built using GnuTLS as TLS/SSL library, setting CURLOPT_SSL_VERIFYPEER option to 0 (i.e. disabling verification that the certificate is valid and was issued by a trusted certificate authority) also disabled server name checks regardless of the value of the CURLOPT_SSL_VERIFYHOST option. This caused libcurl to skip name checks while an application using the library could expect it to be performed. Note: Only enabling VERIFYHOST while disabling VERIFYPEER is insecure unless the application performs its own peer verification equivalent to the verification performed by libcurl when VERIFYPEER is enabled. The curl command line tool is not affected, as it disables both VERIFYPEER and VERIFYHOST when the -k / --insecure command line option is used. Documentation for VERIFYPEER and VERIFYHOST options: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTSSLVERIFYPEER http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTSSLVERIFYHOST Acknowledgements: Red Hat would like to thank the cURL project for reporting this issue. Upstream acknowledges Marc Deslauriers as the original reporter.
This does not affect curl packages shipped in Red Hat Enterprise Linux and Fedora, as they do not use GnuTLS as TLS/SSL backend. The curl packages in Red Hat Enterprise Linux 5 and earlier, as well as mingw*-curl packages in Fedora and EPEL, use OpenSSL backend. The curl packages in Red Hat Enterprise Linux 6 and current Fedora versions use NSS backend. Bug 1029159 comment 0 provides an overview of how these packages are affected or not affected by this problem. Statement: Not vulnerable. This issue did not affect the versions of curl as shipped with Red Hat Enterprise Linux 5 and 6.
Public now via upstream advisory, fix released as part of upstream version 7.34.0. External References: http://curl.haxx.se/docs/adv_20131217.html