mark :: blog :: openssl
In his Black Hat paper and presentation yesterday, Dan Kaminsky highlighted
some more issues he has found relating to SSL hash collisions and other PKI
of the presentationis online now, so I'm sure the PDF paper will follow
shortly. Some of these issues affect open source software, and some parts have
already been addressed, so here is a quick summary including CVE names of the
MD2 signature verification
The first issue is that many web browsers still accept certificates
with MD2 hash signatures, even though MD2 is no longer considered a
cryptographically strong algorithm. This could make it easier for an
attacker to create a malicious certificate that would be treated as
trusted by a browser. It turns out that there are not many valid MD2 hash certificates
around any more, and the main one that does exist is at the trusted
root level anyway (and there is actually no need for a crypto library
to verify the self-signature on a trusted root). So most vendors have
chosen to address this issue by disabling MD2 completely for
certificate verification. This is allocated CVE name CVE-2009-2409 (
single name for all affected products).
OpenSSL. For upstream OpenSSL we have disabled MD2 support
completely. This was done in two stages; the first was a patch in June 2009 that
redundant check of a trusted root self-signed certificate. Then in July,
totally disabled. So this issue does not affect OpenSSL 1.0.0 beta 3 or later.
Although there have not yet been an upstream release of 0.9.8 containing this
fix, a future OpenSSL 0.9.8 (after 0.9.8k) will disable MD2, probably in a few
GnuTLS. The upstream GnuTLS library has for some time meant to
MD2 support, although due to a broken patch it wasn't actually disabled
correctly until January 2009. So this issue does not affect GnuTLS versions
2.6.4 and above, or GnuTLS versions 2.7.4 and above.
NSS (and hence Firefox). The upstream NSS library since version 3.12.3
(April 2009) has disabled MD2 and MD4 by default (although legacy applications
could turn it back on using an environment variable
"NSS_ALLOW_WEAK_SIGNATURE_ALG" if they need to). Mozilla Firefox since version
3.5 has used this NSS version and
is disabled. I suspect this issue will get addressed in a future Firefox 3.0
update in the future too if they rebase to the new NSS.
There is no immediate panic to address this issue as a critical security
issue, as in order for it to be exploited an attacker still has to create a MD2
collision with this root certificate; something that is as of today still a
significant amount of effort.
My CVSS v2 base score for CVE-2009-2409 would be 2.6 (AV:N/AC:H/Au:N/C:N/I:P/A:N)
Differences in Common Name handling
This issue is about how Common Names are checked for validity by
applications. For example if a server presents a certificate with two CN
entries, how does the app validate those. Does it use the first one, the
last one, or all of them?
OpenSSL. OpenSSL provides an API that allow applications to
check CN names any way they want. It turns out that, without sound guidance,
applications have tended to do things differently. A summary of a
in this Red Hat bugzilla comment. But as a CA should validate all CN names in a
certificate being signing, these are really just bugs and do not have a security
Leading 0's in Common Name handling
The second issue is all about inconsistencies in the interpretation of subject
x509 names in certificates. Specifically "issue 2b, subattack 1" is where a
malicious certificate can contain leading 0's in the OID. The idea is that an
attacker could add in some OID into a certificate that, when handled by the
Certificate Authority, would appear to be some extension and ignored, but when
handled by OpenSSL would appear to be the Common Name OID. So the attacker
would present the certificate to a client application and it might think that
the OID is actually a Common Name, and accept the certificate where it otherwise
OpenSSL. This is not a security issue for OpenSSL. Steve
Henson explains: "OpenSSL does tolerate leading 0x80 but it does
_not_ recognize this as commonName because the NID code checks for a precise
match with the encoding. Attempts to print this out will never show commonName
nor will attempts to look up using NID_commonName". However this will be
addressed as a bug fix in the future.
NSS (and hence Firefox). NSS is noted in the paper as having a
similar issue, but again it's not fooled into treating the OID as a Common Name
so this is not a security issue (and therefore I didn't check if this is already
fixed in the new upstream NSS).
OID overflow in Common Name handling
"issue 2b, subattack 2" is where a malicious certificate can have a very large
integer in the OID. The idea is that an attacker could add in some OID into a
certificate that, when handled by the CA, would appear to be some extension and
ignored, but when handled by OpenSSL would overflow and appear to be the Common
Name OID. So the attacker would present the certificate to a client application
using OpenSSL and it might think that the OID is actually a Common Name, and
accept the certificate where it otherwise should not.
OpenSSL. This issue was actually fixed upstream in September 2006
in OpenSSL 0.9.8d by switching to using
the bignum library for
handling the OID. Even for older versions though it's really not a security
issue for the same reason as given earlier: the OpenSSL NID code
checks for a precise match with the encoding. So attempts to print this out
will never show it being a Common Name, nor will attempts to look it up as a
Common Name succeed.
NULL bytes in Common Name handling
"issue 2, attack 2c" is regarding NULL terminators in a Common Name field.
If an attacker is able to get a
carefully-crafted certificate signed by a Certificate Authority trusted by
a browser, the attacker could use the certificate during a man-in-the-middle
attack and potentially confuse the browser into accepting it by mistake.
My CVSS v2 base score for CVE-2009-2408 would be 4.3 (AV:N/AC:M/Au:N/C:N/I:P/A:N)
OpenSSL 'compat mode' subject name injection
"issue 2d" is how the OpenSSL command line utility will output unescaped
subject X509 lines to standard output. So if some utility runs the openssl
application from the command line and parses the text output, and if an attacker
can craft a malicious certificate in such a way they fool a CA into signing it,
they could present it to the utility and possibly fool that utility into
thinking fields were different to what they actually are, perhaps allowing the
certificate to be accepted as legitimate.
This attack requires that some utility will parse the output of OpenSSL
command line using the default 'compat' mode. Applications should never do
this. Upstream OpenSSL are unlikely to address this issue directly, although in
the future the default output mode perhaps could be changed to something other than
'compat', and it's likely a documentation update will remind users that
parsing the output of running such an openssl command is not the right way to
OpenSSL ASN1 printing crash
Also mentioned in the paper is a flaw in the filtering modes when a two or four
byte wide character set is asked to be filtered.
My CVSS v2 base score for CVE-2009-0590 would be 2.6 (AV:N/AC:H/Au:N/C:N/I:N/A:P)
Just finished the security audit for FC4 candidate - For 20030101-20050605 there are a potential 861 CVE named vulnerabilities that could have affected FC4 packages. 759 (88%) of those are fixed because FC4 includes an upstream version that includes a fix, 8 (1%) are still outstanding, and 94 (11%) are fixed with a backported patch. I'll post all the details to fedora-devel-list later in the week.
I'm also giving a keynote about Fedora and security response at FudCon later this month.
A CSO remarked to me a couple of weeks ago that their perception was that OpenSSL had a lot of serious security issues over the years. In fact it's really only had a couple of serious issues, and in total only 15 issues in the last 4 years. So in the style of the Apache vulnerability database I did one for OpenSSL. This is now publically available and we'll keep it up to date. The page is built from a XML database of the issues.
What a busy day; doing the OpenSSL release manager role for the recent security updates, testing packages, dealing with the third parties, being a third party, rolling, pushing, correcting.
What is disturbing is a report from a third party company who is vulnerable to one of the Denial of service issues that said that it wasn't a security issue as their were hundreds of other possible DoS attacks. Actually, this attack causes OpenSSL to crash. We've got a proof of concept, you don't have to send more than a kb of data to get OpenSSL to crash remotely. This can be quite serious if you have a service that can't recover from that. Things like Apache (when running in its default prefork memory model) can recover quite well - they just spawn off a new child to replace the dead one. This is going to use up some extra resources, but depending on the platform it's quite minor (and will stop as soon as the attacker stops sending malicious packets). Not everything that listens to the network that uses OpenSSL is so resiliant.
Going to be in London next weekend?
Hi! I'm Mark Cox. This blog gives my
thoughts and opinions on my security
work, open source, fedora, home automation,
and other topics.