|Summary:||<dev-libs/libgcrypt-1.5.4: Possible side-channel attack on ElGamal encryption subkeys (CVE-2014-5270)|
|Product:||Gentoo Security||Reporter:||Kristian Fiskerstrand (RETIRED) <k_f>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||normal||CC:||alonbl, crypto+disabled, multilib|
|Package list:||Runtime testing required:||---|
Description Kristian Fiskerstrand (RETIRED) 2014-08-08 10:42:08 UTC
Hi! While evaluating the "Get Your Hands Off My Laptop"  paper I missed to describe  a software combination which has not been fixed and is thus vulnerable to the attack described by the paper. If you are using a GnuPG version with a *Libgcrypt version < 1.6.0*, it is possible to mount the described side-channel attack on Elgamal encryption subkeys. To check whether you are using a vulnerable Libgcrypt version, enter gpg2 --version on the command line; the second line of the output gives the Libgcrypt version: gpg (GnuPG) 2.0.25 libgcrypt 1.5.3 In this example Libgcrypt is vulnerable. If you see 1.6.0 or 1.6.1 you are fine. GnuPG versions since 1.4.16 are not affected because they do not use Libgcrypt. The recommendation is to update any Libgcrypt version below 1.6.0 to at least the latest version from the 1.5 series which is 1.5.4. Updating to 1.6.1 is also possible but that requires to rebuild GnuPG. Libgcrypt 1.5.4 has been released yesterday ; for convenience I include the download instructions below. A CVE-id has not yet been assigned. Many thanks to Daniel Genkin for pointing out this problem. Shalom-Salam, Werner  http://www.cs.tau.ac.il/~tromer/handsoff  http://lists.gnupg.org/pipermail/gnupg-announce/2014q3/000349.html  http://lists.gnupg.org/pipermail/gnupg-announce/2014q3/000351.html ############ To re-cap, this seems to be fixed in 1.5.4 which was added to the tree in bug 519350 but has not yet been stabilized and the 1.6 series.
Comment 1 Kristian Fiskerstrand (RETIRED) 2014-08-08 11:26:26 UTC
Arches, please stabilize =dev-libs/libgcrypt-1.5.4 Target stable keywords: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Comment 2 Jeroen Roovers (RETIRED) 2014-08-08 14:02:41 UTC
Why does 1.5.4 have a different SLOT? It conflicts with 1.5.3 on /usr/lib/libgcrypt.so.11
Comment 3 Alon Bar-Lev (RETIRED) 2014-08-08 15:58:03 UTC
(In reply to Jeroen Roovers from comment #2) > Why does 1.5.4 have a different SLOT? It conflicts with 1.5.3 on > /usr/lib/libgcrypt.so.11 indeed... it was a copy of, added due to bug#513718 it probably a mistake.  http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/libgcrypt-1.5.3-r100.ebuild?hideattic=0&revision=1.5&view=markup
Comment 4 Alon Bar-Lev (RETIRED) 2014-08-08 16:00:45 UTC
Seems to be intentional: !dev-libs/libgcrypt:0/11 Multilib, why do we use slots such as this? or I should revert bug#513718 changes?
Comment 5 Alon Bar-Lev (RETIRED) 2014-08-08 16:20:50 UTC
ok, deferred multilib changes to later (libgcrypt-1.5.4-r100). libgcrypt-1.5.4 is exact copy of libgcrypt-1.5.3 now.
Comment 6 Michał Górny 2014-08-08 16:33:08 UTC
The SLOT=11 contains just the library for pre-built software compatibility, i.e. that you can install 1.6* and 1.5* at the same time because you want to use 1.6* but some binary software was linked to .so.11.
Comment 7 Alon Bar-Lev (RETIRED) 2014-08-08 17:34:54 UTC
(In reply to Michał Górny from comment #6) > The SLOT=11 contains just the library for pre-built software compatibility, > i.e. that you can install 1.6* and 1.5* at the same time because you want to > use 1.6* but some binary software was linked to .so.11. Do we need to keep this forever?
Comment 8 Michał Górny 2014-08-08 17:52:00 UTC
(In reply to Alon Bar-Lev from comment #7) > (In reply to Michał Górny from comment #6) > > The SLOT=11 contains just the library for pre-built software compatibility, > > i.e. that you can install 1.6* and 1.5* at the same time because you want to > > use 1.6* but some binary software was linked to .so.11. > > Do we need to keep this forever? No, just as long as there are binary packages that require it :). $ grep -R -l libgcrypt.*:11 app-emulation/emul-linux-x86-baselibs-20140406-r4 app-emulation/emul-linux-x86-baselibs-20140508-r12 app-emulation/emul-linux-x86-baselibs-20140508-r13 app-emulation/emul-linux-x86-baselibs-20140508-r14 app-emulation/emul-linux-x86-baselibs-20140508-r9 dev-db/xtrabackup-bin-2.1.9 dev-db/xtrabackup-bin-2.2.3 media-sound/spotify-0.9.11.27 media-sound/spotify-0.9.4.183-r8 www-client/google-chrome-36.0.1985.125_p1
Comment 9 Jeroen Roovers (RETIRED) 2014-08-08 19:06:22 UTC
Stable for HPPA.
Comment 10 Agostino Sarubbo 2014-08-09 09:42:56 UTC
Comment 11 Agostino Sarubbo 2014-08-09 10:49:28 UTC
Comment 12 Agostino Sarubbo 2014-08-09 13:22:35 UTC
Comment 13 Agostino Sarubbo 2014-08-09 13:22:46 UTC
Comment 14 Agostino Sarubbo 2014-08-10 17:27:28 UTC
Comment 15 Markus Meier 2014-08-13 15:23:47 UTC
Comment 16 Agostino Sarubbo 2014-08-19 07:36:37 UTC
Comment 17 Agostino Sarubbo 2014-08-24 09:03:00 UTC
alpha stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Comment 18 Kristian Fiskerstrand (RETIRED) 2014-08-24 09:53:48 UTC
New GLSA request filed.
Comment 19 Kristian Fiskerstrand (RETIRED) 2014-08-24 10:45:22 UTC
Cleanup done: + 24 Aug 2014; Kristian Fiskerstrand <email@example.com> -libgcrypt-1.5.3.ebuild: + Cleanup vulnerable versions for security bug #519396
Comment 20 GLSAMaker/CVETool Bot 2014-08-29 10:40:17 UTC
This issue was resolved and addressed in GLSA 201408-10 at http://security.gentoo.org/glsa/glsa-201408-10.xml by GLSA coordinator Kristian Fiskerstrand (K_F).