cURL / Mailing Lists / curl-users / Single Mail

curl-users

[Security Adviosory] libcurl embedded zero in cert name

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 12 Aug 2009 11:12:55 +0200 (CEST)

libcurl embedded zero in cert name
==================================

Project cURL Security Advisory, August 12th 2009
http://curl.haxx.se/docs/security.html

1. 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.

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

2. AFFECTED VERSIONS

Affected versions: curl and libcurl 7.4 to and including 7.19.5
Not affected versions: curl and libcurl 7.19.6 and later

   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.

3. THE SOLUTION

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

4. 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!

5. TIME LINE

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.

6. CREDITS

Reported to us by Scott Cantor. Thanks a lot!

Daniel Stenberg wrote the primary patch and this advisory

Peter Sylvester for test case work and patch feedback

Michal Marek and Kamil Dudka provided the backported patches

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Received on 2009-08-12

This message: [ Message body ]
Next message: Jogeshwar Karthik Akundi: "issue with quick reconnect"
Previous message: Ramkumar Harihara Iyer: "Check out my photos on Facebook"

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]