There is an outstanding pull request to resolve this security issue in a different way than the initial commit; unfortunately I’m not well versed enough in the intricacies of DH to conclude if it’s a good patch or not.
I did contact Daniel about making the group_order * 8 - 1 change in the SHA1 function the day the security bulletin was posted and he agreed it needed to be done; but apparently no one has actually committed the change. I have submitted a pull request with the original fix ported to the SHA1 method which is identical to the fedora patch.
Regards,
Will
> On Apr 7, 2016, at 1:17 AM, Kamil Dudka <kdudka_at_redhat.com> wrote:
>
> On Wednesday 06 April 2016 15:08:41 Cody P Schafer wrote:
>> I was looking into CVE-2016-0787 (bits vs bytes confusion within dh
>> exponent generation) and noted that someone had taken a look at the
>> code and commented on the github commit:
>> https://github.com/libssh2/libssh2/commit/ca5222ea819cc5ed797860070b4c6c1aee
>> b28420
>>
>> After some examination myself, it appears that diffie_hellman_sha1 is
>> vulnerable to the same issue that diffie_hellman_sha256 was vulnerable
>> to, and there are other issues with private exponent generation that
>> should be examined.
>
> Yes, this seems to be a known issue:
>
> https://www.libssh2.org/mail/libssh2-devel-archive-2016-02/0029.shtml
>
> In Fedora we apply the following patch on top of libssh2-1.7.0:
>
> http://pkgs.fedoraproject.org/cgit/rpms/libssh2.git/tree/CVE-2016-0787.patch?id=2d448ce0
>
> Daniel, should we apply the patch upstream, too?
>
> I know there are some outstanding issues reported in the above thread but
> they should IMO not prevent this one-liner from being applied as such.
>
> Kamil
>
>> I'm including the comments from github below for posterity:
>>
>> yumkam commented on ca5222e on Feb 23:
>>> Something feels eerily wrong here.
>>> 1) compare diffie_hellman_sha1 and diffie_hellman_sha256; is not there
>>> exactly same problem in sha1 variant? 2) if I was not mistaken, this is
>>> generation of "private exponent"; but "private exponent" need not be as
>>> large as group order! Normal size is "twice as generated key material",
>>> something from 256 bits to 512 bits for usual symmetric algos and key
>>> sizes, see rfc4419 section 6.2 (Private exponent) [1]. That is, it was,
>>> indeed, about 2 times too small before (and still wrong for
>>> diffie_hellman_sha1?), but it is more than 4 times too large now. (Well,
>>> at least later is only performance issue). Disclaimer: I'm not real
>>> cryptographer, but only playing one.
>>> P.S. openssh uses
>>> min(2*max(symmetric_{key,iv,block,mac}_in_bits),p_bits-1)
>>
>> yumkam commented on ca5222e on Feb 23:
>>> Also, for diffie-hellman-group-exchange-*, if p_bits+1 is not multiply of
>>> 8, group_order*8 can be larger than p_bits (by up to 7 bits); thus,
>>> generated group_order*8-1-bit random value x can fail 1 < x < (p-1)/2
>>> test, see rfc4419[2]
>> [1]: https://tools.ietf.org/html/rfc4419#section-6.2
>> [2]: https://tools.ietf.org/html/rfc4419#section-3
>>
>> Checking the code in git today shows the same flaws noted in those
>> comments still exist.
>>
>> _______________________________________________
>> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2016-04-07