Date: Mon, 17 Aug 2015 13:09:08 -0400 (EDT) From: cve-assign@...re.org To: mprpic@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request: GNUTLS-SA-2015-3 double free in certificate DN decoding -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > http://www.gnutls.org/security.html#GNUTLS-SA-2015-3 > > "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: > > https://gitlab.com/gnutls/gnutls/commit/272854367efc130fbd4f1a51840d80c630214e12 > lib/x509/common.c > _gnutls_x509_dn_to_string > + str->data = NULL; Use CVE-2015-6251 for GNUTLS-SA-2015-3. > http://www.openwall.com/lists/oss-security/2015/05/05/8 > I wonder if the following issue in GnuTLS should get a CVE: > http://www.gnutls.org/security.html#GNUTLS-SA-2015-2 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. >> https://lists.gnupg.org/pipermail/gnutls-devel/2015-April/007572.html >> 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 pastebin.com. 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 pastebin.com. 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 http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJV0hRqAAoJEKllVAevmvmslXIH/367Ktcsmy7a4QW5TOunbDl4 1ejMuUYm/S+h1LG73BUgR4MCtyBHFd/GnSLGCJWQamiS5crlAobwEeMO1qE74fBh Ibk2KdYAKTUM1SwuSK9C+u4XdTz/K5qac9B8YwzvMvjULNnqbjkyf3a4N1H2UYB3 rDSFd4qvHK0Mtk+aM76rGfVfyePz10dkc6sGHsp6pnlZl153FeNi69lfdvMbK3Ls vwY+ROvQ/OiFqbrv0HamWytfSyOlpMVEullEMgpwEC7KRrbNQ5U+tdBNe33ZsdXp +1zHqyJ1M76vr4oQp5B+fMEmP0o9sfbLYm/P89hM/h0qA5ls2K2rP+nBqgTtl+s= =Xgcf -----END PGP SIGNATURE-----
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.