Bug 1306021 (CVE-2016-0787)
Summary: | CVE-2016-0787 libssh2: bits/bytes confusion resulting in truncated Diffie-Hellman secret length | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Kurt Seifried <kseifried> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | asn, cperry, daniel, kdudka, ksrot, meissner, sardella, security-response-team, slawomir |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libssh2 1.7.0 | Doc Type: | Bug Fix |
Doc Text: |
A type confusion issue was found in the way libssh2 generated ephemeral secrets for the diffie-hellman-group1 and diffie-hellman-group14 key exchange methods. This would cause an SSHv2 Diffie-Hellman handshake to use significantly less secure random parameters.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2016-03-10 08:02:31 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: | 1310049, 1310050, 1310051, 1310053, 1311214, 1311215, 1311216, 1311217 | ||
Bug Blocks: | 1306023 |
Description
Kurt Seifried
2016-02-09 20:56:22 UTC
There is a bits/bytes confusion bug and generate the an anormaly short ephemeral secret for the diffie-hellman-group1 and diffie-hellman-group14 key exchange methods. The resulting secret is 128 bits long, instead of the recommended sizes of 1024 and 2048 bits respectively. There are practical algorithms (Baby steps/Giant steps, Pollard's rho) that can solve this problem in O(2^63) operations. The group_order value in diffie_hellman_sha1() passed to _libssh2_bn_rand() should be in bits. The values used are 128 and 256. Is this already being communicated with libssh2 upstream? Yeps, I'm CC'ed here and I think I count as upstream! :-) Indeed! I should have looked before asking... Daniel, for libssh the embargo is currently set for Feb 23rd, 2016 14:00 CET. Are you fine with this or should we move it? That's probably gonna work out fine. We have a new release in the works since forever but we should be in sync with this pretty good. So have you identified/written any particular fix to this problem other than multiplying the number of bytes by 8 to pass in bits correctly? Like below diff --git a/src/kex.c b/src/kex.c index 6349457..99362f8 100644 --- a/src/kex.c +++ b/src/kex.c @@ -751,11 +751,11 @@ static int diffie_hellman_sha256(LIBSSH2_SESSION *session, /* Zero the whole thing out */ memset(&exchange_state->req_state, 0, sizeof(packet_require_state_t)); /* Generate x and e */ - _libssh2_bn_rand(exchange_state->x, group_order, 0, -1); + _libssh2_bn_rand(exchange_state->x, group_order * 8, 0, -1); _libssh2_bn_mod_exp(exchange_state->e, g, exchange_state->x, p, exchange_state->ctx); /* Send KEX init */ /* packet_type(1) + String Length(4) + leading 0(1) */ In libssh we solved it like this: if (key_type == DH_GROUP1_SHA1) { group_order = 1023; } else { group_order = 2047; } bignum_rand(x, group_order); We want to ensure x and y are selected in an uniform distribution between 1 and (p-1)/2, that is the advised range for DH private keys. Choosing a 1024 or 2048 bits secret wouldn't be wrong, but has a risk of being above p and very likely to be above p/2. Removing a bit ensures it doesn't wrap above p, and is easy to write, so it's a good tradeoff. Makes sense? The embargo is currently set for Feb 23rd, 2016 14:00 CET. But based on what? Who asked for that embargo and why so long? Your involvement in/driving of this problem is very puzzling to me. See comment #5 and comment #6. So to whom have you offered/promised this embargo? Redhat? I just tried to help. libssh will release on that date. If you want another date, then talk to secalert. I will leave that all to you now ... You're helping out, sure, and I'm grateful for the notification of this problem but you're also leaving out information that makes this hard to understand. I've worked in open source for decades, I've done security advisories with CVEs over 40 times in several projects. This is the first time ever for me where a vendor announces the problem, already has the CVE and already has an embargo - for the upstream project. And then you're not even telling me who you've told about this or who for the embargo is. Did you inform distros@openwall? Should I? Daniel, unless you did it already, please send your questions/requests to secalert , which is the channel with guaranteed service level. Upstream patch: http://www.libssh2.org/CVE-2016-0787.patch External References: http://www.libssh2.org/adv_20160223.html (In reply to Daniel Stenberg from comment #14) > You're helping out, sure, and I'm grateful for the notification of this > problem but you're also leaving out information that makes this hard to > understand. > > I've worked in open source for decades, I've done security advisories with > CVEs over 40 times in several projects. This is the first time ever for me > where a vendor announces the problem, already has the CVE and already has an > embargo - for the upstream project. > > And then you're not even telling me who you've told about this or who for > the embargo is. > > Did you inform distros@openwall? Should I? Hi Daniel, Kurt is attending a conference today. So if this requires a reply sooner, then the general secalert@ address has a 24hr SLA to get replies. That being said, since the issue was reported to Red Hat, we aim to provide this upfront co-ordination as you described. I /assume/ that yes, Kurt has communicated to the distro list to this date, giving them appropriate time to react. I'll chase down on my end to see if Kurt can provide additional information, or another member of our team. Regards, Cliff I'm all good. I emailed distros@, I have the CVE, I have a drafted advisory and the release will go out on Feb 23. libssh2 1.7.0 was released upstream with this fix included. Public via: https://www.libssh2.org/adv_20160223.html Created mingw-libssh2 tracking bugs for this issue: Affects: fedora-all [bug 1311215] Affects: epel-7 [bug 1311217] Created libssh2 tracking bugs for this issue: Affects: fedora-all [bug 1311214] Affects: epel-5 [bug 1311216] Acknowledgments: Name: Aris Adamantiadis libssh2-1.6.0-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. libssh2-1.5.0-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. libssh2-1.5.0-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Via RHSA-2016:0428 https://rhn.redhat.com/errata/RHSA-2016-0428.html |