Bug 1306021 (CVE-2016-0787) - CVE-2016-0787 libssh2: bits/bytes confusion resulting in truncated Diffie-Hellman secret length
Summary: CVE-2016-0787 libssh2: bits/bytes confusion resulting in truncated Diffie-Hel...
Status: CLOSED ERRATA
Alias: CVE-2016-0787
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20160223,repor...
Keywords: Security
Depends On: 1311217 1310049 1310050 1310051 1310053 1311214 1311215 1311216
Blocks: 1306023
TreeView+ depends on / blocked
 
Reported: 2016-02-09 20:56 UTC by Kurt Seifried
Modified: 2016-11-08 15:54 UTC (History)
9 users (show)

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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:0428 normal SHIPPED_LIVE Moderate: libssh2 security update 2016-03-10 12:40:39 UTC

Description Kurt Seifried 2016-02-09 20:56:22 UTC
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 21:52:51 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.

Comment 2 Kamil Dudka 2016-02-10 14:18:51 UTC
Is this already being communicated with libssh2 upstream?

Comment 3 Daniel Stenberg 2016-02-10 14:22:08 UTC
Yeps, I'm CC'ed here and I think I count as upstream! :-)

Comment 4 Kamil Dudka 2016-02-10 14:26:28 UTC
Indeed!  I should have looked before asking...

Comment 5 Andreas Schneider 2016-02-11 14:21:10 UTC
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 23:01:37 UTC
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 10:27:01 UTC
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 13:05:46 UTC
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 09:43:28 UTC
The embargo is currently set for Feb 23rd, 2016 14:00 CET.

Comment 10 Daniel Stenberg 2016-02-17 09:45:38 UTC
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 09:53:29 UTC
See comment #5 and comment #6.

Comment 12 Daniel Stenberg 2016-02-17 09:55:29 UTC
So to whom have you offered/promised this embargo? Redhat?

Comment 13 Andreas Schneider 2016-02-17 09:57:45 UTC
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 10:02:43 UTC
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 15:38:36 UTC
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 09:22:54 UTC
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 17:06:13 UTC
(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 19:34:44 UTC
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 13:42:13 UTC
libssh2 1.7.0 was released upstream with this fix included.

Comment 21 Adam Mariš 2016-02-23 15:29:05 UTC
Public via:

https://www.libssh2.org/adv_20160223.html

Comment 22 Adam Mariš 2016-02-23 15:33:46 UTC
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 15:33:54 UTC
Created libssh2 tracking bugs for this issue:

Affects: fedora-all [bug 1311214]
Affects: epel-5 [bug 1311216]

Comment 24 Adam Mariš 2016-02-23 15:54:06 UTC
Acknowledgments:

Name: Aris Adamantiadis

Comment 27 Fedora Update System 2016-02-26 19:22:01 UTC
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 16:22:56 UTC
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 20:12:41 UTC
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 07:41:03 UTC
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.