Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 591534 (CVE-2016-6313) - <dev-libs/libgcrypt-1.7.3: Critical security vulnerability in RNG
Summary: <dev-libs/libgcrypt-1.7.3: Critical security vulnerability in RNG
Status: RESOLVED FIXED
Alias: CVE-2016-6313
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: https://lists.gnupg.org/pipermail/gnu...
Whiteboard: A2 [glsa cve]
Keywords:
: 591526 (view as bug list)
Depends on:
Blocks: gnupg-2.1, gnupg-2.2 588016
  Show dependency tree
 
Reported: 2016-08-17 17:18 UTC by Kristian Fiskerstrand
Modified: 2016-10-10 11:06 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Fiskerstrand gentoo-dev Security 2016-08-17 17:18:23 UTC
From ${URL} (note CVE in announcement is wrong)

Hello!

The GnuPG Project is pleased to announce the availability of new
Libgcrypt and GnuPG versions to *fix a critical security problem*.

Felix Dörre and Vladimir Klebanov from the Karlsruhe Institute of
Technology found a bug in the mixing functions of Libgcrypt's random
number generator: An attacker who obtains 4640 bits from the RNG can
trivially predict the next 160 bits of output.  This bug exists since
1998 in all GnuPG and Libgcrypt versions.


Impact
======
All Libgcrypt and GnuPG versions released before 2016-08-17 are affected
on all platforms.

A first analysis on the impact of this bug in GnuPG shows that existing
RSA keys are not weakened.  For DSA and Elgamal keys it is also unlikely
that the private key can be predicted from other public information.
This needs more research and I would suggest _not to_ overhasty revoke
keys.


Solution
========
If you are using a vendor supplied version of GnuPG or Libgcrypt:

 * Wait for an update from your vendor.

If you are using a GnuPG-2 version (2.0.x or 2.1.x):

 * Update Libgcrypt.  We have released these fixed versions of
   Libgcrypt: 1.7.3, 1.6.6, and 1.5.6.  See below for download
   information.

If you are using GnuPG-1 version (1.4.x): 

 * Update as soon as possible to GnuPG 1.4.21.  See below for download
   information.
Comment 1 Kristian Fiskerstrand gentoo-dev Security 2016-08-17 17:22:40 UTC
*** Bug 591526 has been marked as a duplicate of this bug. ***
Comment 2 Kristian Fiskerstrand gentoo-dev Security 2016-08-17 17:31:36 UTC
commit 89839c6d27d465c4af1ded04805a9e302ba59a65
Author: Kristian Fiskerstrand <k_f@gentoo.org>
Date:   Wed Aug 17 19:29:51 2016 +0200

    dev-libs/libgcrypt: Critical security version bump to 1.7.3
    
    Gentoo-Bug: 591534
    
    Package-Manager: portage-2.3.0
Comment 3 Kristian Fiskerstrand gentoo-dev Security 2016-08-17 17:33:55 UTC
Arches, please stabilize:
=dev-libs/libgcrypt-1.7.3
Stable targets: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Comment 4 Kristian Fiskerstrand gentoo-dev Security 2016-08-17 17:43:06 UTC
GnuPG 1.4 is handled in bug 591536
Comment 5 Andrew Savchenko gentoo-dev 2016-08-18 07:00:46 UTC
Shold libgcrypt:0/11 be bumped as well (to 1.5.6)?
Comment 6 Kristian Fiskerstrand gentoo-dev Security 2016-08-18 07:38:50 UTC
(In reply to Andrew Savchenko from comment #5)
> Shold libgcrypt:0/11 be bumped as well (to 1.5.6)?

if anything will be bumped it 11/11, 0/11 will be removed per bug 567382, so any application still relyign on 1.5 will need to be dropped to ~arch if it hasn't already
Comment 7 Kristian Fiskerstrand gentoo-dev Security 2016-08-18 08:13:25 UTC
(In reply to Kristian Fiskerstrand from comment #6)
> (In reply to Andrew Savchenko from comment #5)
> > Shold libgcrypt:0/11 be bumped as well (to 1.5.6)?
> 
> if anything will be bumped it 11/11, 0/11 will be removed per bug 567382, so
> any application still relyign on 1.5 will need to be dropped to ~arch if it
> hasn't already

commit 0b57f6b05e0ebdf9547c0176bf5d0bdd18e87ede
Author: Kristian Fiskerstrand <k_f@gentoo.org>
Date:   Thu Aug 18 10:11:53 2016 +0200

    dev-libs/libgcrypt: Cleanup vulnerable version in 11/11
    
    Package-Manager: portage-2.3.0

commit 084dbc57853cea50dc3c68c064729121c542fde2
Author: Kristian Fiskerstrand <k_f@gentoo.org>
Date:   Thu Aug 18 10:09:49 2016 +0200

    dev-libs/libgcrypt: Security bump of 11/11 slot to 1.5.6
Comment 8 Kristian Fiskerstrand gentoo-dev Security 2016-08-18 08:39:33 UTC
commit d266cee915c186a65e4ac94e9726744c37077cdf
Author: Kristian Fiskerstrand <k_f@gentoo.org>
Date:   Thu Aug 18 10:38:10 2016 +0200

    dev-libs/libgcrypt: Remove vulnerable 1.5.5 in 0/11 slot
    
    This is the final package version in 0/11 slot
    
    Gentoo-Bug: 567382
    Gentoo-Bug: 591534
    
    Package-Manager: portage-2.3.0
Comment 9 Andrew Savchenko gentoo-dev 2016-08-18 10:22:31 UTC
(In reply to Kristian Fiskerstrand from comment #6)
> (In reply to Andrew Savchenko from comment #5)
> > Shold libgcrypt:0/11 be bumped as well (to 1.5.6)?
> 
> if anything will be bumped it 11/11, 0/11 will be removed per bug 567382, so
> any application still relyign on 1.5 will need to be dropped to ~arch if it
> hasn't already

The problem is that we don't have a well defined policy how to remove package from stable; I asked multiple times for this on gentoo-dev ML, but was only answered that the Council allowed to remove packages from stable if they are in the way, though this is no recommended, with no guidelines how to do this.

The issue I'm talking about is sys-power/suspend-1.0 which needs old libgcrypt. Stabilization for a fixed version was hanged due to stabilization of one of its optional deps (splashutils) for more than half a year (I mean bug 567524). It was fixed just today and I suppose only thanks to this bug. I was really itching to move splashutils to ~arch, since the package is poorly maintained anyway, but we have no policy on:

1) what are time slots for:
a) waiting for stabilization before any action;
b) pinging arch team;
c) how long to wait after a warning for moving from stable before taking any action.

2) How to handle reverse dependencies:
a) Should separate bugs for moving to unstable (or stable.mask'ing optional dependencies) be created for a full reverse dependency tree, or just explain the issue in the original bug and CC their maintainers?
b) How long to wait for reaction from maintainers of reverse deps? They may really want that packages (or their optional dependencies) to be kept in stable.

I should probably to post these questions to the ML once more...
Comment 10 Kristian Fiskerstrand gentoo-dev Security 2016-08-18 12:53:18 UTC
(In reply to Andrew Savchenko from comment #9)
> (In reply to Kristian Fiskerstrand from comment #6)
> > (In reply to Andrew Savchenko from comment #5)
> > > Shold libgcrypt:0/11 be bumped as well (to 1.5.6)?
> > 
> > if anything will be bumped it 11/11, 0/11 will be removed per bug 567382, so
> > any application still relyign on 1.5 will need to be dropped to ~arch if it
> > hasn't already
> 
> The problem is that we don't have a well defined policy how to remove
> package from stable; I asked multiple times for this on gentoo-dev ML, but
> was only answered that the Council allowed to remove packages from stable if
> they are in the way, though this is no recommended, with no guidelines how
> to do this.
> 
> The issue I'm talking about is sys-power/suspend-1.0 which needs old
> libgcrypt. Stabilization for a fixed version was hanged due to stabilization
> of one of its optional deps (splashutils) for more than half a year (I mean
> bug 567524). It was fixed just today and I suppose only thanks to this bug.
> I was really itching to move splashutils to ~arch, since the package is
> poorly maintained anyway, but we have no policy on:
> 
> 1) what are time slots for:
> a) waiting for stabilization before any action;
> b) pinging arch team;
> c) how long to wait after a warning for moving from stable before taking any
> action.
> 
> 2) How to handle reverse dependencies:
> a) Should separate bugs for moving to unstable (or stable.mask'ing optional
> dependencies) be created for a full reverse dependency tree, or just explain
> the issue in the original bug and CC their maintainers?
> b) How long to wait for reaction from maintainers of reverse deps? They may
> really want that packages (or their optional dependencies) to be kept in
> stable.
> 
> I should probably to post these questions to the ML once more...

Since we have recently started a working group evaluating stable tree etc, these kinds of questions seems natural to have as part of that WG, #gentoo-wg-stable or wg-stable@g.o alias
Comment 11 Agostino Sarubbo gentoo-dev 2016-08-18 14:54:28 UTC
amd64 stable
Comment 12 Jeroen Roovers gentoo-dev 2016-08-18 23:33:09 UTC
Stable for HPPA PPC64.
Comment 13 Tobias Klausmann gentoo-dev 2016-08-31 10:58:06 UTC
Stable on alpha.
Comment 14 Markus Meier gentoo-dev 2016-09-01 11:31:43 UTC
arm stable
Comment 15 Agostino Sarubbo gentoo-dev 2016-09-29 08:42:44 UTC
x86 stable
Comment 16 Agostino Sarubbo gentoo-dev 2016-09-29 09:37:43 UTC
sparc stable
Comment 17 Agostino Sarubbo gentoo-dev 2016-09-29 12:38:29 UTC
ppc stable
Comment 18 Agostino Sarubbo gentoo-dev 2016-09-29 13:30:56 UTC
ia64 stable.

Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.
Comment 19 Kristian Fiskerstrand gentoo-dev Security 2016-10-03 17:12:03 UTC
commit 6b43fa49439f73a6a1908e66bc50ebea324cfd4a
Author: Kristian Fiskerstrand <k_f@gentoo.org>
Date:   Mon Oct 3 19:10:46 2016 +0200

    dev-libs/libgcrypt: Cleanup vulnerable version
    
    Cleanup c.f
    Gentoo-Bug: 591534
    
    Package-Manager: portage-2.3.1
Comment 20 Kristian Fiskerstrand gentoo-dev Security 2016-10-03 23:28:58 UTC
Added to existing GLSA request
Comment 21 GLSAMaker/CVETool Bot gentoo-dev 2016-10-03 23:32:12 UTC
CVE-2016-6313 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-6313):
  PRNG output is predictable
Comment 22 GLSAMaker/CVETool Bot gentoo-dev 2016-10-10 11:06:26 UTC
This issue was resolved and addressed in
 GLSA 201610-04 at https://security.gentoo.org/glsa/201610-04
by GLSA coordinator Kristian Fiskerstrand (K_F).