Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 05 Aug 2009 18:55:39 +0200
From: "Matthias Andree" <>
To:, "Steven M. Christey"
Subject: Re: CVE request: fetchmail <= 6.3.10 SSL certificate
 NUL prefix verification bypass

Am 05.08.2009, 18:30 Uhr, schrieb Tomas Hoger <>:

> And than there is OpenSSL, which, as I've been told, expects
> applications to do name checking.  So it's probably safe to assume that
> many / majority of client applications using OpenSSL are likely to be
> affected by some variant of this problem (either via CommonNames or
> subjectAltNames).  I'm not sure if single CVE should be used here for
> all, or dozens of CVEs, one for each.  It's likely going to be mess
> either way.  I'm adding CC on Steven for advice.  Steven, at least one
> CVE has already been allocated privately for similar case.

How about this:

- for fetchmail, assign an individual CVE Id (as each other of the  
affected applications)

- for this problem class (NUL in CN/subjectAltName allows impersonation of  
other sites), add a sort of "umbrella CVE" that will reference the  
individual application CVEs. Would this work?

For fetchmail which uses OpenSSL, the issue was indeed the use of  

The fix that works for the CommonName NUL checks the length returned from  
X509_NAME_get_text_by_NID versus strlen() of the same string, and will  
fail the certificate verification if there is a length mismatch, because  
we then know that there is at least one NUL character that is part of the  

An alternative would be making sure that we always compare at least  
min(X509_NAME_get_text_by_NID(...), strlen(expected_name)) characters, but  
that's actually more effort.

A separate fetchmail commit adds a "sdump()" function that allocates and  
reformats the string to use ANSI-C \xAB-style escapes for non-printable  
characters so that users can actually see the difference in their logs; I  
understand that some distributors will skip that patch, so it goes like  

char buf[257], *tt;

i = X509_NAME_get_text_by_NID(..., buf, sizeof(buf) - 1);
fprintf(dbgstream, "Common Name: \"%s\"\n", (tt = sdump(buf, i)));

If anyone cares about such a function (license: LGPL v2.1 or later), grab  
it from
(it uses xmalloc() which is something along the lines of void  
*xmalloc(size_t i) { void *x=malloc(i); if (!x) abort(); return x; })

Or complain that I'm missing a POSIX standard function that does the same  

FWIW, I haven't yet tested if this works for NUL in subjectAltNames, as I  
currently don't know how to generate such a certificate (can be  
self-signed) without writing major amounts of code.

If someone has a certificate that has embedded NULs in subjectAltNames  
that I can use for testing, please send it along together with its key so  
that I can check the fix also works in that code path.

Also, if someone knows a SSL/TLS server (whichever SSL version and  
protocol) that uses subjectAltNames in a legitimate way, please let me  
know hostname and port so I can test that there are no regressions for  
regular servers.


Matthias Andree

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.