Bug 944456 - (CVE-2015-5738) VUL-0: CVE-2015-5738: openssl: RSA-CRT key leak in custom version of OpenSSL
VUL-0: CVE-2015-5738: openssl: RSA-CRT key leak in custom version of OpenSSL
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
Depends on:
Blocks: 944835
  Show dependency treegraph
Reported: 2015-09-04 08:13 UTC by Victor Pereira
Modified: 2019-12-09 18:34 UTC (History)
5 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Victor Pereira 2015-09-04 08:13:23 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.

Comment 1 Swamp Workflow Management 2015-09-04 22:00:16 UTC
bugbot adjusting priority
Comment 2 Vítězslav Čížek 2015-09-07 12:14:35 UTC
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))
949  {
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.
Comment 3 Victor Pereira 2015-09-07 12:22:02 UTC
not affected
Comment 4 Andreas Stieger 2015-09-08 07:32:16 UTC
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 <wk@gnupg.org>
> 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
> user.
Comment 5 Bernhard Wiedemann 2015-09-08 10:00:12 UTC
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
Comment 8 Marcus Meissner 2015-09-08 13:20:06 UTC
openssl is not affected by this problem.