Bug 988589 - (CVE-2013-4242) CVE-2013-4242 GnuPG susceptible to Yarom/Falkner flush+reload cache side-channel attack
CVE-2013-4242 GnuPG susceptible to Yarom/Falkner flush+reload cache side-chan...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20130722,repor...
: Security
Depends On: 988592 988593 988594 988595 988596 1015736 1015737 1017001 1017002 1017003 1017004
Blocks: 988590 1015687
  Show dependency treegraph
 
Reported: 2013-07-25 18:32 EDT by Vincent Danen
Modified: 2015-11-24 10:36 EST (History)
10 users (show)

See Also:
Fixed In Version: gnupg 1.4.14, libgcrypt 1.5.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 15:04:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2013-07-25 18:32:54 EDT
It was announced that GnuPG 1.x [1] and Libgcrypt [2] were susceptible to the Yarom/Falkner flush+reload cache side-channel attack on the RSA secret exponent, which can be used to obtain the majority of an RSA secret key from memory.  An abstract of the paper is noted below:

Flush+Reload is a cache side-channel attack that monitors access to
data in shared pages. In this paper we demonstrate how to use the
attack to extract private encryption keys from GnuPG.  The high
resolution and low noise of the Flush+Reload attack enables a spy
program to recover over 98% of the bits of the private key in a
single decryption or signing round. Unlike previous attacks, the
attack targets the last level L3 cache. Consequently, the spy
program and the victim do not need to share the execution core of
the CPU. The attack is not limited to a traditional OS and can be
used in a virtualised environment, where it can attack programs
executing in a different VM.

Upstream noted the following:

I general the use of private keys on multi-user machines is imminent
dangerous due to a variety of possibly attacks.  Example for such
attacks are locally exploitable vulnerabilities and all kind of side
channel attacks which can't be mitigated by the operating system.  Thus
the best advise is to use a private key only on a fully trusted machine;
i.e. a machine with full control over the software which may run on it.

However, it is common to put private keys on servers for example to
process encrypted mail.  If the server hardware is shared with other
users it is thus important to update GnuPG so to avoid the described
attack.  On a pure desktop machine, with only one user, mounting this
attack is probably not effective because there are easier ways to gain
access to the machine and thus the keys.  For best protection of private
keys, smartcards are often the best choice.

A patch for GnuPG 1.x is available [3], as well as for Libgcrypt (for GnuPG 2.x) [4].

[1] http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000330.html
[2] http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000329.html
[3] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=35646689f4b80955ff7dbe1687bf2c479c53421e#patch2
[4] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=287bf0e543f244d784cf8b58340bf0ab3c6aba97


External References:

http://eprint.iacr.org/2013/448
Comment 2 Vincent Danen 2013-07-25 18:39:26 EDT
Created mingw-libgcrypt tracking bugs for this issue:

Affects: fedora-all [bug 988594]
Comment 3 Vincent Danen 2013-07-25 18:39:32 EDT
Created libgcrypt tracking bugs for this issue:

Affects: fedora-all [bug 988593]
Comment 4 Vincent Danen 2013-07-25 18:39:38 EDT
Created gnupg tracking bugs for this issue:

Affects: fedora-all [bug 988592]
Comment 5 Vincent Danen 2013-07-25 18:39:44 EDT
Created mingw32-libgcrypt tracking bugs for this issue:

Affects: epel-5 [bug 988596]
Comment 6 Vincent Danen 2013-07-26 15:08:02 EDT
This was assigned CVE-2013-4242 via http://www.openwall.com/lists/oss-security/2013/07/26/7
Comment 7 Fedora Update System 2013-08-01 23:21:25 EDT
libgcrypt-1.5.3-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2013-08-01 23:22:34 EDT
libgcrypt-1.5.3-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2013-08-09 13:07:39 EDT
gnupg-1.4.14-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2013-08-14 22:56:40 EDT
gnupg-1.4.14-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Huzaifa S. Sidhpurwala 2013-08-27 01:11:14 EDT
We believe that there are several deterrents to active exploitation of this vulnerability.

1. The attacker needs to be logged into the machine containing the private key, when gpg decryption takes place. Therefore only multi-user systems are affected.

2. The exploit takes advantage of being able to cause the L3 cache to flush and reload at an exact time. In intel architecture L3 cache is common to all the CPU cores, therefore the exploit does not have to run on a particular core. However this also implies that this is highly CPU arch. dependent. 

3. It is recommended not to store important private keys on disk/process them in shared memory, specially if multi-user systems are being used for this purpose. Dedicated hardware devices like Smart cards are better options.
Comment 13 Huzaifa S. Sidhpurwala 2013-08-27 01:15:14 EDT
Statement:

This issue affects the version of gnupg as shipped with Red Hat Enterprise Linux 5. This issue affects the version of libgcrypt as shipped with Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this issue as having moderate security impact, a future update may address this flaw. More technical details on this flaw are available at https://bugzilla.redhat.com/show_bug.cgi?id=988589#c12
Comment 18 errata-xmlrpc 2013-10-24 11:26:59 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2013:1458 https://rhn.redhat.com/errata/RHSA-2013-1458.html
Comment 19 errata-xmlrpc 2013-10-24 11:28:33 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6

Via RHSA-2013:1457 https://rhn.redhat.com/errata/RHSA-2013-1457.html

Note You need to log in before you can comment on or make changes to this bug.