Bug 1366105 (CVE-2016-6313)
| Summary: | CVE-2016-6313 libgcrypt: PRNG output is predictable | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Huzaifa S. Sidhpurwala <huzaifas> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | awilliam, bcl, bressers, carnil, cperry, fweimer, huzaifas, mjc, robatino, sardella, security-response-team, sgallagh, tmraz, yselkowi |
| Target Milestone: | --- | Keywords: | Reopened, Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libgcrypt 1.7.3, libgcrypt 1.6.6, libgcrypt 1.5.6, gnupg 1.4.21 | Doc Type: | Release Note |
| Doc Text: |
A design flaw was found in the libgcrypt PRNG (Pseudo-Random Number Generator). An attacker able to obtain the first 580 bytes of the PRNG output could predict the following 20 bytes.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-08 06:51:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1368041, 1386488, 1386489, 1386490, 1386491, 1390852, 1390853 | ||
| Bug Blocks: | 1364841 | ||
|
Description
Huzaifa S. Sidhpurwala
2016-08-11 05:02:26 UTC
Acknowledgements: Name: Felix Dörre, Vladimir Klebanov External Reference: https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html Created libgcrypt tracking bugs for this issue: Affects: fedora-all [bug 1368041] Note that CVE-2016-6316 used in announcement is wrong, it should be CVE-2016-6313 as used in commit messages. Upstream commit for libgcrypt 1.7: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=8dd45ad957b54b939c288a68720137386c7f6501 Upstream commit applied to libgcrypt embedded in gnupg 1.4: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=c6dbfe89903d0c8191cf50ecf1abb3c8458b427a Analysis: This is essentially a flaw in the way libgcrypt's PRNG works. The flaw exists in the mixing of the entropy pool, which reduces the entropy by atleast 20 bytes. libgcrypt PRNG is modeled after a proposal by Guttmann with several notable differences. The weakness in the PRNG results in the fact that by taking the bytes [L-40, L-20)U[0,44] of the output and hashing them with the hash context chaining buffer set to bytes [L-40,L-20), an attacker can predict the bytes [L-20,L) Attack: The attacker needs to obtain 4640 bits of data from the PRNG. There may be several ways for an attacker to do this for example entropy is heavily used when a GPG key pair is generated. However the paper states that after 4640 bits of data is read by the attacker, he can calculate the next consecutive 160 bits. Practically reading so much entropy directly from libgcrypt PRNG is very difficult to pull-off (For GPG key pair generation, several calculations needs to be done on the output of the PRNG before it can used as a key etc.) So even though the attack is easy to conduct, its beyond the scope of practicality for any attacker (remote or even local). Proposed as a Blocker and Freeze Exception for 25-alpha by Fedora user bcl using the blocker tracking app because: gnupg Fix critical security bug in the RNG [CVE-2016-6313] seems like a good enough reason to block/break freeze. meh, the discussion above makes it not seem terribly critical (i.e. practically exploitable). I guess I'd be OK for an FE if the change was small enough. It does not smell like a blocker to me, though. Based on the discussion in here, I'm -1 to blocking Alpha for this and -1 on a Freeze Exception. I don't have a clear picture of what might go wrong with this if we change it at this point. The patch looks fairly innocuous, but since it's a key part of pseudo-random number generation, I'm not going to pretend to know if it's a low risk to include it. I'd rather we skip it for Alpha and get it into u-t for people to try out. +1 to Stephen, this is not a critical bug - at most the impact is moderate. That's three -1 blocker votes, marking as RejectedBlocker. (In reply to Adam Williamson from comment #18) > That's three -1 blocker votes, marking as RejectedBlocker. Please don't set that on bugs against Security Response product, there's Fedora bug 1368041 where that belongs. Moving. sorry, that wasn't me, though; it was bcl who nominated it. I just followed the process from there. gnupg-1.4.21-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. libgcrypt-1.6.6-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. gnupg-1.4.21-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. libgcrypt-1.6.6-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. gnupg-1.4.21-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. Does mingw-libgcrypt also need an update? The whiteboard doesn't mention it either way. If the version is older than the versions mentioned in the Fixed in field, then yes. (In reply to Tomas Mraz from comment #28) > If the version is older than the versions mentioned in the Fixed in field, > then yes. Both Fedora and EPEL7 mingw-libgcrypt are 1.6.3. And that means it is vulnerable. (In reply to Tomas Mraz from comment #30) > And that means it is vulnerable. I still don't see mingw-libgcrypt bugs filed. Created mingw-libgcrypt tracking bugs for this issue: Affects: fedora-all [bug 1390852] Affects: epel-7 [bug 1390853] This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2016:2674 https://rhn.redhat.com/errata/RHSA-2016-2674.html |