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 removed the redundant check of a trusted root self-signed certificate. Then in July, MD2 was 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 weeks.

• GnuTLS. The upstream GnuTLS library has for some time meant to have disabled 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 therefore MD2 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 few OpenSSL applications is 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 impact

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 should not.

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

• NSS (and hence Firefox). This issue affected NSS and is assigned CVE-2009-2408. The upstream NSS library since version 3.12.3 (April 2009) has fixes to address this issue. Therefore Firefox 3.5 is not affected.

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.

• OpenSSL. 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 use OpenSSL.

OpenSSL ASN1 printing crash

• OpenSSL. This was reported by Dan to OpenSSL and fixed in March 2009. This was allocated CVE name CVE-2009-0590. Therefore OpenSSL 0.9.8k and later contains a fix for this issue.

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.

OpenSSL Security

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.

So in the last month: I've learnt that sending the press a written statement usually gets you a better and more accurate quote than talking to them. It's probably the British accent that throws them. I've learnt that no matter how hard you try you can't find everyone who uses OpenSSL in their product to tell them in advance about security issues, and the ones you miss end up being annoyed. I've learnt that the latest attempt to cure my migraines has a side effect in that I don't get nervous before giving presentations (it felt like I was watching myself from above). I've learnt that April fools jokes on the web are not funny (well apart from the "Klingon Eye for the Human Guy" one and our Apache PDA one from a few years ago).

Just a month before the end of life of Red Hat Linux 9 I finally got around to upgrading some old Red Hat 7.1 machines to run Advanced Server 2.1AS; only one reboot and about 20 minutes of my time required. I was so pleased with myself I spent an hour sending in one of my patches for ZoneMinder which is used to record and upload cctv stuff that goes on outside my house.

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.

pics from my twitter:

popular tags: [all], apache, apachecon, apacheweek, cve, cvss, fedora, financial, geocaching, ha, metrics, microsoft, nashville, north carolina, red hat summit, redhat, security, trips