Bug 510202

Summary:	differences in handling of SSL Common Names (Kaminsky)
Product:	[Other] Security Response	Reporter:	Mark J. Cox <mjc>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	unspecified	CC:	hyc, ludwig.nussel, osoukup, security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-19 09:07:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mark J. Cox 2009-07-08 10:57:10 UTC

In his upcoming Blackhat paper and presentation Dan Kaminsky
highlights some more issues he has found relating to SSL hash
collisions and related vulnerabilities.

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?

It turns out that OpenSSL applications do things in different ways.  However as the research continued it was noted that the general rule is that a certificate authority must validate all the CN in a certificate they sign.  So it's not the case that you could sneak a certificate request past a CA with a legitimate and malicious CN in such a way that an application would be fooled with a security context.

The consensus of the meetings with Dan Kaminsky is that applications should validate all CN in a presented certificate (if there is no subjectAltName, SAN).

Although RFC2818 states that if there is no SAN you should use the 'most specific CN'.

No OpenSSL code change will be made, OpenSSL already provides an API that allows an application to check multiple CN if it so wishes.

Comment 1 Mark J. Cox 2009-07-08 10:58:14 UTC

Multiple Common Names handled differently

I've been looking at various applications that use OpenSSL to check CN
and how they deal with multiple CNs.  So I found things we ship in Red
Hat products (not necessarily the latest versions of each):

Just uses least specific CN:
     cyrus-imapd 2.2.12
     freeradius 1.1.13
     postfix 2.2.10
     fetchmail 6.3.6
     openldap 2.3.27
     gftp 2.0.17
     sendmail 8.13.1
     dovecot 1.0
     postgresql 7.3.19
     curl 7.10.6

neon: the code quoted in the draft Kaminsky paper is from a very old (more than 5 years old) version of neon.  Neon since 0.22 at least has used the most specific CN if there is no subjectAltName (using different function X509_NAME_get_index_by_NID)

curl 7.12.1: uses most specific CN if no subjectAltName, but older versions (7.10.6) used least specific

w3m 0.5.1: uses least specific CN if no subjectAltName

squid 2.6: uses any CN if no subjectAltName

wget 1.10.2: uses least specific CN but code notes it should be 'most specific'

libesmtp 0.8.12: uses least specific CN, but code notes it should be 'any'

pam_pkcs11 0.5.3: gets all CN

Comment 3 Mark J. Cox 2009-07-30 15:40:44 UTC

presentation given by Dan yesterday at Blackhat, removing embargo.

Comment 4 Kevin Kofler 2009-07-31 00:37:15 UTC

Also removing EMBARGOED from the title as the embargo has been removed.

Comment 5 Howard Chu 2009-08-21 19:10:45 UTC

Just fyi, this was fixed in OpenLDAP CVS on August 10 for our OpenSSL and GnuTLS support. It was fixed on July 30 for our MozNSS support.

Comment 6 Tomas Hoger 2009-08-26 13:09:23 UTC

Hey Howard, thanks for heads-up.  I presume you are referring to following commits:

MozNSS:
http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls_m.c.diff?r1=1.8&r2=1.11&f=h

OpenSSL:
http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls_o.c.diff?r1=1.8&r2=1.11&f=h

GnuTLS:
http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls_g.c.diff?r1=1.13&r2=1.14&f=h

I presume those fixes should also address CVE-2009-2408-like problem where they existed before (from quick testing, it seems at least OpenSSL variant had issues with NULs in CNs).  Have you looked at / tested that too?  Thanks!

Comment 7 Howard Chu 2009-08-26 17:03:32 UTC

Yes, those commits also address CVE-2009-2408, tested / confirmed. (Actually our gnutls code was already correct on that issue.)

Comment 8 Tomas Hoger 2009-08-27 06:33:09 UTC

Thank you!  Yes, from the patch, it looked that GnuTLS variant was unaffected.