Bug 988589 (CVE-2013-4242) - CVE-2013-4242 GnuPG susceptible to Yarom/Falkner flush+reload cache side-channel attack
Summary: CVE-2013-4242 GnuPG susceptible to Yarom/Falkner flush+reload cache side-chan...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-4242
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20130722,repor...
Depends On: 988592 988593 988594 988595 988596 1015736 1015737 1017001 1017002 1017003 1017004
Blocks: 988590 1015687
TreeView+ depends on / blocked
 
Reported: 2013-07-25 22:32 UTC by Vincent Danen
Modified: 2019-06-08 19:39 UTC (History)
10 users (show)

Fixed In Version: gnupg 1.4.14, libgcrypt 1.5.3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 19:04:31 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1457 normal SHIPPED_LIVE Moderate: libgcrypt security update 2013-10-24 19:23:34 UTC
Red Hat Product Errata RHSA-2013:1458 normal SHIPPED_LIVE Moderate: gnupg security update 2013-10-24 19:22:57 UTC

Description Vincent Danen 2013-07-25 22:32:54 UTC
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 22:39:26 UTC
Created mingw-libgcrypt tracking bugs for this issue:

Affects: fedora-all [bug 988594]

Comment 3 Vincent Danen 2013-07-25 22:39:32 UTC
Created libgcrypt tracking bugs for this issue:

Affects: fedora-all [bug 988593]

Comment 4 Vincent Danen 2013-07-25 22:39:38 UTC
Created gnupg tracking bugs for this issue:

Affects: fedora-all [bug 988592]

Comment 5 Vincent Danen 2013-07-25 22:39:44 UTC
Created mingw32-libgcrypt tracking bugs for this issue:

Affects: epel-5 [bug 988596]

Comment 6 Vincent Danen 2013-07-26 19:08:02 UTC
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-02 03:21:25 UTC
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-02 03:22:34 UTC
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 17:07:39 UTC
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-15 02:56:40 UTC
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 05:11:14 UTC
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 05:15:14 UTC
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 15:26:59 UTC
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 15:28:33 UTC
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.