                      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
 
      http://curl.haxx.se/CVE-2009-2417/curl-7.19.5-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.19.0-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.18.1-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.16.4-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.15.5-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.15.1-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.12.1-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.11.0-CVE-2009-2417.patch
      http://curl.haxx.se/CVE-2009-2417/curl-7.10.6-CVE-2009-2417.patch
 
  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

Page updated December 8, 2009.
web site info

File upload with ASP.NET