curl / Docs / curl CVEs / embedded zero in cert name

CVE-2009-2417

embedded zero in cert name

Project curl Security Advisory, August 12th 2009 Permalink

VULNERABILITY

SSL and TLS Server certificates contain one or more fields with server name or otherwise matching patterns. These strings are stored as content and length within the certificate, and thus there is no particular terminating character.

curl's OpenSSL interfacing code did faulty assumptions about those names and patterns being zero terminated, allowing itself to be fooled in case a certificate would get a zero byte embedded into one of the name fields. To illustrate, a name that would show this vulnerability could look like:

"example.com\0.haxx.se"

This cert is thus made for "haxx.se" but curl would erroneously verify it with no complaints for "example.com".

According to a recently published presentation, this kind of zero embedding has been proven to be possible with at least one CA.

INFO

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2009-2417 to this issue.

CWE-170: Improper Null Termination

Severity: High

AFFECTED VERSIONS

This vulnerability is only present in OpenSSL-specific parts of the code. If you build curl or libcurl to use GnuTLS or NSS instead, you must instead make sure you use a secure version of those libraries. They have both recently also been found vulnerable to this same flaw.

Also note that (lib)curl is used by many applications, and not always advertised as such.

We have not researched curl versions earlier than 7.4 but we estimate that usage of such old versions is very rare.

SOLUTION

libcurl 7.19.6 makes sure that the length from the cert is used for verification and not the zero terminating byte.

RECOMMENDATIONS

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 7.19.6

B - Apply the suitable patch and rebuild

C - Rebuild curl with a safe version of GnuTLS or NSS

Note that both GnuTLS and NSS also suffered from this same vulnerability so a "safe version" thus implies a version with this flaw already fixed!

TIMELINE

We were notified by Scott Cantor on July 30th, 2009.

We discussed solutions and a first patch was written and tested on July 31st.

Vendor-sec was contacted on August 3, 2009.

We agreed on and coordinated the synchronous disclosure of this problem together with the curl 7.19.6 release.

curl 7.19.6 was released on August 12th 2009, just before this flaw was publicly disclosed.

CREDITS

Peter Sylvester for test case work and patch feedback

Michal Marek and Kamil Dudka provided the backported patches

Thanks a lot!