Date: Thu, 27 Feb 2014 09:24:35 +0100 From: Tomas Hoger <thoger@...hat.com> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com Subject: Re: CVE Request - GnuTLS corrects flaw in certificate verification (3.1.x/3.2.x) On Thu, 27 Feb 2014 00:37:56 -0500 (EST) cve-assign@...re.org wrote: > Use CVE-2009-5138 for the > > https://gitorious.org/gnutls/gnutls/commit/c8dcbedd1fdc312f5b1a70fcfbc1afe235d800cd > > issue. This says "Initialy reported by Daniel Kahn Gillmor on > 9/1/2008" but that seems to be a typo of 9/1/2009 (aka 2009-01-09), > because the actual report was in: > > http://lists.gnutls.org/pipermail/gnutls-devel/2009-January/002888.html Yes, 2009 looks right, and 2008 mentioned in the commit text looks like a typo. Linked gnutls-devel post is the same one mentioned in Red Hat bug with the gmane link. > Is this setting in gnutls-cli itself a vulnerability, because > GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is an unsafe flag for any > general-purpose application? For example, > > http://lists.gnutls.org/pipermail/gnutls-devel/2009-January/002892.html > > says: > > GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT > > This one is quite dangerous. It allows any intermediate V1 > certificate to be used as a signer. This means that if I manage to > get a CA to give me a V1 personal certificate, I can act as a CA if > this flag is set. Note there are two flags - GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT and GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT (note the _ANY_ somewhere near the middle of one of the names). Current GnuTLS documentation describes them as: http://gnutls.org/manual/gnutls.html#Verifying-a-certificate-in-the-context-of-TLS-session GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT Allow trusted CA certificates with version 1. This is safer than GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT , and should be used instead. That way only signers in your trusted list will be allowed to have certificates of version 1. This is the default. GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT Allow CA certificates that have version 1 (both root and intermediate). This might be dangerous since those haven’t the basicConstraints extension. Must be used in combination with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT . As far as I can see, support for V1 CA certificates in GnuTLS evolved over time. It seems they were rejected initially, and GnuTLS provided single flag GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT to allow them anywhere in the chain. 1.2.1 has this change: - Improved the semantics of GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT, to allow only trusted Version 1 CAs and introduced GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT which has the old semantics. The aim of the change was apparently to make it possible to accept V1 CAs that are in the application's trust store, but not accept intermediates that are not. The default remain unchanged - V1s rejected by default. This change is consistent with how TLS libraries are less strict about certain attributes of (root) certificates configured in trust stores. As those often have long validity (10-20 years), they are permitted to use what is not permitted further down the chain (such as the mentioned V1 rather than V3, or use weak hashing algorithm such as md5 or even md2 not long ago). GnuTLS version 2.11.5 has this change related to V1 CA certs: ** libgnutls: Reverted default behavior for verification and introduced GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT. Thus by default V1 trusted CAs are allowed, unless the new flag is specified. Where GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT is: GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT Do not allow trusted CA certificates that have version 1. This option is to be used to deprecate all certificates of version 1. Hence 2.11.5 made GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT the default, and the new flag needs to be used to have trusted V1s rejected. The gnutls-cli setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT in pre-2.11.5 versions is equivalent to the current default. I haven't checked if gnutls-cli started setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT in 1.2.1 or only some version later (it does not seem to be mentioned in the NEWS file), its default was changed few times too. I do not believe there is any need for "unsafe hardcoded configuration" CVE for gnutls-cli. > (In other words, all three CVEs would have the same impact -- > something roughly like "allows remote attackers to have an unintended > ability to issue new certificates by using an arbitrary X.509 V1 > certificate -- but two of the CVEs [CVE-2014-1959, CVE-2009-5138] > have a root cause of logic errors in flag operations, whereas the > proposed third CVE has a root cause of a hardcoded unsafe > configuration choice in gnutls-cli.) The two CVEs assigned so far are for: GnuTLS accepts V1 intermediate CA certificates not configured in the trust store, while they are meant to be rejected. Attacker able to get V1 certificate (that is meant to be leaf certificate) from a trusted CA can use it to issue new certificates that were incorrectly accepted by GnuTLS. Accepting V1 CA certificates in the trust store or V1 leaf certificates is considered ok. -- Tomas Hoger / Red Hat Security Response Team
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.