Re: CVE request: fetchmail <= 6.3.10 SSL certificate NUL prefix verification bypass

["Matthias Andree" <matthias.andree () gmx de>]

Am 05.08.2009, 18:30 Uhr, schrieb Tomas Hoger <thoger () redhat com>:

> 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  
strcasecmp().

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

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  
this:

/******************************************************************/
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)));
free(tt);
/******************************************************************/

If anyone cares about such a function (license: LGPL v2.1 or later), grab  
it from

http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/sdump.h
http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/sdump.c
(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  
(-8



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.

HTH

--
Matthias Andree