Bug 1306021 - (CVE-2016-0787) CVE-2016-0787 libssh2: bits/bytes confusion resulting in truncated Diffie-Hellman secret length
CVE-2016-0787 libssh2: bits/bytes confusion resulting in truncated Diffie-Hel...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20160223,repor...
: Security
Depends On: 1311217 1310049 1310050 1310051 1310053 1311214 1311215 1311216
Blocks: 1306023
  Show dependency treegraph
 
Reported: 2016-02-09 15:56 EST by Kurt Seifried
Modified: 2016-11-08 10:54 EST (History)
9 users (show)

See Also:
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 03:02:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2016-02-09 15:56:22 EST
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.
Comment 1 Andreas Schneider 2016-02-09 16:52:51 EST
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.
Comment 2 Kamil Dudka 2016-02-10 09:18:51 EST
Is this already being communicated with libssh2 upstream?
Comment 3 Daniel Stenberg 2016-02-10 09:22:08 EST
Yeps, I'm CC'ed here and I think I count as upstream! :-)
Comment 4 Kamil Dudka 2016-02-10 09:26:28 EST
Indeed!  I should have looked before asking...
Comment 5 Andreas Schneider 2016-02-11 09:21:10 EST
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?
Comment 6 Daniel Stenberg 2016-02-11 18:01:37 EST
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.
Comment 7 Daniel Stenberg 2016-02-14 05:27:01 EST
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) */
Comment 8 Andreas Schneider 2016-02-15 08:05:46 EST
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?
Comment 9 Andreas Schneider 2016-02-17 04:43:28 EST
The embargo is currently set for Feb 23rd, 2016 14:00 CET.
Comment 10 Daniel Stenberg 2016-02-17 04:45:38 EST
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.
Comment 11 Andreas Schneider 2016-02-17 04:53:29 EST
See comment #5 and comment #6.
Comment 12 Daniel Stenberg 2016-02-17 04:55:29 EST
So to whom have you offered/promised this embargo? Redhat?
Comment 13 Andreas Schneider 2016-02-17 04:57:45 EST
I just tried to help. libssh will release on that date. If you want another date, then talk to secalert@redhat.com. I will leave that all to you now ...
Comment 14 Daniel Stenberg 2016-02-17 05:02:43 EST
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?
Comment 15 Kamil Dudka 2016-02-17 10:38:36 EST
Daniel, unless you did it already, please send your questions/requests to secalert@redhat.com , which is the channel with guaranteed service level.
Comment 16 Martin Prpič 2016-02-18 04:22:54 EST
Upstream patch:

http://www.libssh2.org/CVE-2016-0787.patch

External References:

http://www.libssh2.org/adv_20160223.html
Comment 17 Clifford Perry 2016-02-18 12:06:13 EST
(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
Comment 18 Daniel Stenberg 2016-02-18 14:34:44 EST
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.
Comment 20 Daniel Stenberg 2016-02-23 08:42:13 EST
libssh2 1.7.0 was released upstream with this fix included.
Comment 21 Adam Mariš 2016-02-23 10:29:05 EST
Public via:

https://www.libssh2.org/adv_20160223.html
Comment 22 Adam Mariš 2016-02-23 10:33:46 EST
Created mingw-libssh2 tracking bugs for this issue:

Affects: fedora-all [bug 1311215]
Affects: epel-7 [bug 1311217]
Comment 23 Adam Mariš 2016-02-23 10:33:54 EST
Created libssh2 tracking bugs for this issue:

Affects: fedora-all [bug 1311214]
Affects: epel-5 [bug 1311216]
Comment 24 Adam Mariš 2016-02-23 10:54:06 EST
Acknowledgments:

Name: Aris Adamantiadis
Comment 27 Fedora Update System 2016-02-26 14:22:01 EST
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.
Comment 28 Fedora Update System 2016-03-09 11:22:56 EST
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.
Comment 29 Fedora Update System 2016-03-09 15:12:41 EST
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.
Comment 30 errata-xmlrpc 2016-03-10 02:41:03 EST
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

Note You need to log in before you can comment on or make changes to this bug.