Project curl Security Advisory, December 21, 2016 - Permalink
curl's TLS server certificate checks are flawed on Windows CE.
This vulnerability occurs in the verify certificate function when comparing a
wildcard certificate name (as returned by the Windows API function
CertGetNameString)
to the hostname used to make the connection to the
server.
The vulnerability can be triggered with an overly permissive wildcard SAN in
the server certificate such as a DNS name of *.com
. When the function
compares the cert name to the connection hostname, the wildcard character is
removed from the cert name and the connection hostname is checked to see if it
ends with the modified cert name. This means a hostname of example.com would
match a DNS SAN of *.com
, among other variations. This approach violates
recommendations in RFC 6125 and could lead to MITM attacks.
This vulnerability only happens on libcurl built for Windows CE using the Schannel TLS backend.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2016-9952 to this issue.
CWE-295: Improper Certificate Validation
Severity: Medium
This flaw exists in the following libcurl versions.
- Affected versions: libcurl 7.27.0 to and including 7.51.0
- Not affected versions: libcurl < 7.27.0 and libcurl >= 7.52.0
- Introduced-in: https://github.com/curl/curl/commit/4ab2d26cb83dfbb74ba9eeaaa4835b4dd12883d4
libcurl is used by many applications, but not always advertised as such!
In version 7.52.0, the certificate check is changed to instead use the libcurl certificate verifying function used for a few other TLS backends that does not contain these flaws.
We suggest you take one of the following actions immediately, in order of preference:
A - Upgrade curl and libcurl to version 7.52.0
B - Apply the patch to your version and rebuild
C - Do not use the Schannel backend on Windows CE
It was first reported to the curl project on November 29 2016.
We contacted MITRE on December 13.
curl 7.52.0 was released on December 21 2016, coordinated with the publication of this advisory.
- Reported-by: Dan McNulty
- Patched-by: Dan McNulty
Thanks a lot!