[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
