It was found that during the SSHv2 handshake when libssh2 is to get a suitable value for 'group order' in the Diffle Hellman negotiation, it would pass in number of bytes to a function that expected number of bits. This would result in the library generating numbers using only an 8th the number of random bits than what were intended: 128 or 256 bits instead of 1023 or 2047. Using such drastically reduced amount of random bits for Diffie Hellman weakended the handshake security significantly.
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
Upstream commit: https://github.com/libssh2/libssh2/commit/ca5222ea819cc5ed797860070b4c6c1aeeb28420
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.
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