Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 13:09:08 -0400 (EDT)
Subject: Re: CVE request: GNUTLS-SA-2015-3 double free in certificate DN decoding

Hash: SHA256

> "Kurt Roeckx reported that decoding a specific certificate with very
> long DistinguishedName (DN) entries leads to double free, which may
> result to a denial of service. Since the DN decoding occurs in almost
> all applications using certificates it is recommended to upgrade the
> latest GnuTLS version fixing the issue. Recommendation: Upgrade to
> GnuTLS 3.4.4, or 3.3.17."
> The upstream patch that fixes this issue is available at:

> lib/x509/common.c
> _gnutls_x509_dn_to_string
> +  str->data = NULL;

Use CVE-2015-6251 for GNUTLS-SA-2015-3.

> I wonder if the following issue in GnuTLS should get a CVE:


We consider this a potentially complex question. There are multiple
ways to think about a case in which a client or server bug has the
possible side effect of an algorithm choice that should not have
occurred. The perspective from which the CVE project thinks about
these cases is not necessarily the same as the perspective from which
a protocol designer, or a cryptographic-library author, would think
about these cases.


>> GnuTLS does not by default support MD5 signatures. Indeed the RSA-MD5
>> signature-hash algorithm needs to be explicitly enabled using the
>> priority option VERIFY_ALLOW_SIGN_RSA_MD5. In the NORMAL and SECURE
>> profiles, GnuTLS clients do not offer RSA-MD5 in the signature
>> algorithms extension. However, we find that all GnuTLS clients still
>> accept RSA-MD5 in the ServerKeyExchange and GnuTLS servers still
>> accept RSA-MD5 in the ClientCertificateVerify.
>> To see the bug, connect with GnuTLS to an openssl 1.0.1m server with a
>> modified ssl/s3_srvr.c (attached) which always signs the
>> ServerKeyExchange with RSA-MD5.  When gnutls-cli connects to a server,
>> its signature algorithms extension only advertises signature/hash
>> algorithms that use the SHA family. Notably, it should not allow any
>> MD5 signature. However, when our server sends it an RSA-MD5 signature,
>> NSS does not check that this algorithm is included in the allowed
>> algorithms and quietly accepts it, hence downgrading the expected
>> security of the connection.

We think that the implied perspective here is "the actual security is
weaker than the intended security, and therefore the bug must be
categorized as a vulnerability in the cryptographic library."

An alternative perspective is:

  The issue does not cross any privilege boundary. Regardless of
  whether this bug exists, the server was already able to weaken
  security to any extent that it chose. The server could, for example,
  automatically publish the cleartext of all sessions to
  The attacker role in the described scenario is a server operator who
  has intentionally decided to modify OpenSSL code to always sign with
  RSA-MD5. The server operator may, equivalently, have decided to use
  a non-OpenSSL product that is only capable of signing with RSA-MD5.
  Similarly, the server operator may have accidentally enabled a
  product configuration that signs with RSA-MD5 even though the server
  operator hadn't wanted that. In general, an observation that a
  server implements the TLS protocol does not mean that the client
  user is entitled to conclude anything about the ultimate
  confidentiality or integrity of any data supplied by the client
  user. The ultimate confidentiality and integrity depends, to a very
  large extent, on how the server site is operated and maintained. An
  especially concerned client user could choose to participate in TLS
  sessions only in cases where operations on the server side had
  passed a satisfactory third-party audit. Indeed there is a bug in the
  _gnutls_session_sign_algo_enabled function within the client code,
  but a bug cannot be categorized as a vulnerability unless it enables
  an attacker to accomplish a type/severity of impact that the
  attacker was not already able to accomplish.

The 007572.html message doesn't discuss an attack scenario for "GnuTLS
servers still accept RSA-MD5 in the ClientCertificateVerify" but we
think the alternative perspective may be similar. No privilege
boundary is crossed, because the client was already able to weaken
security to any extent that it chose, e.g., by publishing its client
certificate and the associated private key to

Going back to the "all GnuTLS clients still accept RSA-MD5 in the
ServerKeyExchange" bug for the entire remainder of this message, it
may be possible to argue that the attacker role is not the server
operator, and instead the attacker role is a man in the middle. The
argument here is "because there might be server code somewhere with a
bug that causes an unintentional choice of RSA-MD5 for signing, the
client has a vulnerability unless the client is able to detect that
and refuse to let the session happen." In this scenario, the "server
code somewhere with a bug that causes an unintentional choice" issue
could have a CVE ID for that server-side vulnerability (i.e., if the
code is generally available rather than in-house code). Before
assigning a CVE ID for the client's _gnutls_session_sign_algo_enabled
bug, it may be reasonable to require that the "server code somewhere
with a bug that causes an unintentional choice" actually exists.

In other words, if the only known relevance of the
_gnutls_session_sign_algo_enabled bug is in situations where the
server has chosen to have weak security, then ultimately no privilege
boundary is crossed, and no CVE ID is needed. If the relevance of the
_gnutls_session_sign_algo_enabled bug is in an actual (not
hypothetical) situation where an in-the-wild server bug is causing
accidental RSA-MD5 signing, and the _gnutls_session_sign_algo_enabled
bug means that the intended client-side countermeasure is missing,
then a CVE ID is needed.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


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.