Bug 988589 (CVE-2013-4242)

Summary:	CVE-2013-4242 GnuPG susceptible to Yarom/Falkner flush+reload cache side-channel attack
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	bcl, carnil, erik-fedora, huzaifas, jjaburek, jkurik, jorton, rdieter, rjones, tmraz
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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 19:04:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	988592, 988593, 988594, 988595, 988596, 1015736, 1015737, 1017001, 1017002, 1017003, 1017004
Bug Blocks:	988590, 1015687

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