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 <kdu...@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
