[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.ux67y1wb1e62zd@balu.cs.uni-paderborn.de>
Date: Wed, 05 Aug 2009 18:55:39 +0200
From: "Matthias Andree" <matthias.andree@....de>
To: oss-security@...ts.openwall.com, "Steven M. Christey"
<coley@...us.mitre.org>
Subject: Re: CVE request: fetchmail <= 6.3.10 SSL certificate
NUL prefix verification bypass
Am 05.08.2009, 18:30 Uhr, schrieb Tomas Hoger <thoger@...hat.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
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.
