With the upgrade to 6.5 under FreeBSD I can no longer log into Cisco devices. I traced the problem down to the code fragment below, which was a change made in late January. During the key exchange under 6.5 this is a clue: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent Compared to 6.2: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent I reverted the patch in my source and the problem goes away. I am unfamiliar with the OpenSSH source so I do not know what is the correct thing to do. Index: kexgexc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/kexgexc.c,v retrieving revision 1.15 diff -u -p -r1.15 kexgexc.c --- kexgexc.c 12 Jan 2014 08:13:13 -0000 1.15 +++ kexgexc.c 25 Jan 2014 10:04:23 -0000 @@ -55,7 +55,7 @@ kexgex_client(Kex *kex) int min, max, nbits; DH *dh; - nbits = dh_estimate(kex->we_need * 8); + nbits = dh_estimate(kex->dh_need * 8); if (datafellows & SSH_OLD_DHGEX) { /* Old GEX request */
The problem is Cisco does not correctly implement RFC4419, specifically when asked for a preferred group size larger than its largest group it fails rather than returning a group it does have that's within the allowed min/max bounds. There's been some discussion on the mailing list: http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-February/032177.html Non-code workaround: "KexAlgorithms diffie-hellman-group14-sha1,diffie-hellman-group1-sha1" in ~/.ssh/config for the device in question.
Could you please paste the server's banner? If you run "ssh -v yourserver" you'll see a line something like: debug1: Remote protocol version 1.99, remote software version OpenSSH_6.4 If we know exactly what implementation the remote device reports then we can add a work-around for it. Thanks.
I found the banner information for at least on affected implementation in this redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1053107 debug1: Remote protocol version 1.99, remote software version Cisco-1.25 debug1: no match: Cisco-1.25 It is not clear to me which versions are affected though.
Created attachment 2627 [details] Cap DH-GEX sizes for buggy Cisco servers. Compiled but otherwise untested, I don't have access to the affected equipment.
Created attachment 2629 [details] Cap DH-GEX sizes for buggy Cisco servers. adjusted group size in the wrong direction (MIN vs MAX). Updated patch attached.
Someone was able to give me access to two Ciscos, one with the bug and one without (thanks, Steinar!) and I was able to test the patch. Unfortunately they both have the same protocol banner, so we can't selectively blacklist only the affected implementations. $ ssh -vvv -o KexAlgorithms=diffie-hellman-group-exchange-sha1 cisco-with-bug [...] debug1: Remote protocol version 2.0, remote software version Cisco-1.25 debug1: no match: Cisco-1.25 [...] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent Connection closed by 2001:67c:29f4::19 $ ssh -vvv -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -c aes256-cbc cisco-without-bug [...] debug1: Remote protocol version 2.0, remote software version Cisco-1.25 debug1: no match: Cisco-1.25 [...] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug2: bits set: 2078/4096 With patch: $ ssh -vvv -o KexAlgorithms=diffie-hellman-group-exchange-sha1 cisco-with-bug [...] debug1: Remote protocol version 2.0, remote software version Cisco-1.25 debug1: match: Cisco-1.25 pat Cisco-1.* compat 0x40000000 [...] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug2: bits set: 2016/4096 $ ssh -vvv -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -c aes256-cbc cisco-without-bug [...] debug1: Remote protocol version 2.0, remote software version Cisco-1.25 debug1: match: Cisco-1.25 pat Cisco-1.* compat 0x40000000 [...] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug2: bits set: 2087/4096 Looks like it works.
Patch has been applied and will be in the next release. Thanks!
Just for my confirmation: The banner message is sent already after the KEX has happened and thus an attacker cannot do downgrade attacks, right?
No, the banner is sent before the KEX (it's the first thing on the wire) but it is included in the exchange hash[0] which is later signed by the server as part of the DH key exchange, so it is protected from tampering by a MITM. [0] https://tools.ietf.org/html/rfc4253#section-8
Close all resolved bugs after 7.3p1 release