|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:|
|Version:||unspecified||CC:||bcl, carnil, erik-fedora, huzaifas, jjaburek, jkurik, jorton, rdieter, rjones, tmraz|
|Fixed In Version:||gnupg 1.4.14, libgcrypt 1.5.3||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-06-13 19:04:31 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|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  and Libgcrypt  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 , as well as for Libgcrypt (for GnuPG 2.x) .  http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000330.html  http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000329.html  http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=35646689f4b80955ff7dbe1687bf2c479c53421e#patch2  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