Bugzilla – Bug 944456
VUL-0: CVE-2015-5738: openssl: RSA-CRT key leak in custom version of OpenSSL
Last modified: 2019-12-09 18:34:38 UTC
Back in 1996, Arjen Lenstra described an attack against an optimization (called the Chinese Remainder Theorem optimization, or RSA-CRT for short). If a fault happened during the computation of a signature (using the RSA-CRT optimization), an attacker might be able to recover the private key from the signature (an “RSA-CRT key leak”). At the time, use of cryptography on the Internet was uncommon, and even ten years later, most TLS (or HTTPS) connections were immune to this problem by design because they did not use RSA signatures. This changed gradually, when forward secrecy for TLS was recommended and introduced by many web sites.
An observer of the private key leak can use this information to cryptographically impersonate the server, after redirecting network traffic, conducting a man-in-the-middle attack. Either the client making the TLS handshake can see this leak, or a passive observer capturing network traffic. The key leak also enables decryption of connections which do not use forward secrecy, without the need for a man-in-the-middle attack. However, forward secrecy must be enabled in the server for this kind of key leak to happen in the first place, and with such a server configuration, most clients will use forward secrecy, so an active attack will be required for configurations which can theoretically lead to RSA-CRT key leaks.
bugbot adjusting priority
In order for anyone to exploit this, the RSA operation would need to produce an incorrect result.
Possible reasons for that are a bug in the bignum implementation (something like bug 912296), faulty hardware or somehow corrupted private key (bit-flipping, etc).
There's an easy countermeassure: to verify the computed RSA signature.
NSS does that.
Others, like openjdk (CVE-2015-0478), libgcrypt or libnettle don't include this countermeasure.
OpenSSL verifies the signature when computing RSA using CRT.
But instead of returning an error when it doesn't match, it recomputes the result using the non-optimized method:
948 if (!BN_is_zero(vrfy))
950 /* 'I' and 'vrfy' aren't congruent mod n. Don't leak
951 * miscalculated CRT output, just do a raw (slower)
952 * mod_exp and return that instead. */
The authors of the paper believe that this implementation is safe.
Reassigning to security team.
Hardening in libgcrypt 1.6.4:
> * Always verify a created RSA signature to avoid private key leaks
> due to hardware failures.
> From b85c8d6645039fc9d403791750510e439731d479 Mon Sep 17 00:00:00 2001
> From: Werner Koch <email@example.com>
> Date: Mon, 31 Aug 2015 23:13:27 +0200
> Subject: [PATCH] rsa: Add verify after sign to avoid Lenstra's CRT attack.
> * cipher/rsa.c (rsa_sign): Check the CRT.
> Failures in the computation of the CRT (e.g. due faulty hardware) can
> lead to a leak of the private key. The standard precaution against
> this is to verify the signature after signing. GnuPG does this itself
> and even has an option to disable this. However, the low performance
> impact of this extra precaution suggest that it should always be done
> and Libgcrypt is the right place here. For decryption is not done
> because the application will detect the failure due to garbled
> plaintext and in any case no key derived material will be send to the
This is an autogenerated message for OBS integration:
This bug (944456) was mentioned in
https://build.opensuse.org/request/show/329647 13.2+13.1 / libgcrypt
openssl is not affected by this problem.