| Summary: | <dev-libs/libgcrypt-1.7.3: Critical security vulnerability in RNG | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Kristian Fiskerstrand (RETIRED) <k_f> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bertrand, bircoph, crypto+disabled, hanno, k_f |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=591536 | ||
| Whiteboard: | A2 [glsa cve] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 552936, 588016 | ||
*** Bug 591526 has been marked as a duplicate of this bug. *** 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 Arches, please stabilize: =dev-libs/libgcrypt-1.7.3 Stable targets: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 GnuPG 1.4 is handled in bug 591536 Shold libgcrypt:0/11 be bumped as well (to 1.5.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 (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 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 (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... (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 amd64 stable Stable for HPPA PPC64. Stable on alpha. arm stable x86 stable sparc stable ppc stable ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one. 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 Added to existing GLSA request CVE-2016-6313 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-6313): PRNG output is predictable 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). |
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.