Hi! While evaluating the "Get Your Hands Off My Laptop" [1] paper I missed to describe [2] 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 [3]; 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 [1] http://www.cs.tau.ac.il/~tromer/handsoff [2] http://lists.gnupg.org/pipermail/gnupg-announce/2014q3/000349.html [3] 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.
Arches, please stabilize =dev-libs/libgcrypt-1.5.4 Target stable keywords: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Why does 1.5.4 have a different SLOT? It conflicts with 1.5.3 on /usr/lib/libgcrypt.so.11
(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[1], added due to bug#513718 it probably a mistake. [1] 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
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?
ok, deferred multilib changes to later (libgcrypt-1.5.4-r100). libgcrypt-1.5.4 is exact copy of libgcrypt-1.5.3 now.
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.
(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?
(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
Stable for HPPA.
ppc stable
ppc64 stable
amd64 stable
x86 stable
sparc stable
arm stable
ia64 stable
alpha stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
New GLSA request filed.
Cleanup done: + 24 Aug 2014; Kristian Fiskerstrand <k_f@gentoo.org> -libgcrypt-1.5.3.ebuild: + Cleanup vulnerable versions for security bug #519396
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).
