| Summary: | SSH to Nortel/Avaya switch fails | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | James Sneeringer <jsneerin> | ||||||
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> | ||||||
| Status: | CLOSED INVALID | ||||||||
| Severity: | major | CC: | djm, dtucker, jsneerin | ||||||
| Priority: | P5 | ||||||||
| Version: | 6.2p1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
|
Description
James Sneeringer
2013-06-05 01:07:06 AEST
Created attachment 2293 [details]
Output from "ssh -vvv" on version 6.1p1
Created attachment 2294 [details]
Output from "ssh -vvv" on version 6.2p1
The only noticeable difference in the debug output is that openssh is offering the hmac-md5-etm@openssh.com MACs although the since the server doesn't support them they're not selected. Please try disabling this via "ssh -o MACs=hmac-md5 yourswitch". The debug trace looks like the server is crashing. The default value for this in 6.1 was "hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96" which is 107 bytes. The default value in 6.2 is "hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com, hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96" which is 377 bytes. It would not surprise me if the server is overrunning a fixed size buffer, I would guess 256 bytes. If this is the case, it's quite possibly exploitable. I'm marking this bug private until the vendor has had a chance to be notified. Reducing the list of MACs offered fixes the problem, thanks! I've just added the affected switches to my ~/.ssh/config file with a shorter MACs line for now as a workaround. Given that this doesn't appear to be an OpenSSH bug at all, I leave it to you as to whether you want to keep it open. For what it's worth, all that my Avaya switches log when this happens is "#5 Failed login from IP address: 10.10.64.130". I've since learned that an update (6.3.1.039) for these switches is available. There is no mention of any SSH issues resolved in this release, but I'll test it on a spare unit anyway and report back any change in behavior. depending on how prevalent this is, maybe we should add a compatibility fallback for these servers. I'd like to give the vendor a chance to look at this before doing anything further, including marking this bug public. Could you please let us know what they say? I see the same behavior with the latest code for our Avaya switches. I believe I've narrowed down the behavior. There are two aspects to it: 1. The magic number seems to be 287. Any list of MACs exceeding 287 bytes results in the observed behavior. However... 2. This particular version of Mocana only supports hmac-md5, hmac-md5-96, hmac-sha1, and hmac-sha1-96. Any MAC negotiation not containing one of those will be rejected with a specific message from the server, regardless of length. I agree with Darren that there is probably a fixed-size buffer being overrun somewhere, and is resulting in undesirable behavior. It can be worked around by manually configuring the MACs option for known Mocana servers, but ultimately I think it's their bug to fix. I'll open a trouble ticket with Avaya for this, and hopefully they'll push it upstream to Mocana. I will followup with any details they provide. Thanks. The MACs are part of the KEXINIT packet (see http://openssh.com/txt/rfc4253.txt section 7.1) so your magic value may vary depending on what values you have in other fields, eg Ciphers and HostKeyAlgorithms. Did you ever get any kind of response from the vendor? The banner does not provide any kind of version information, so any compat hacks we do would have to be an all-or-nothing thing: debug1: Remote protocol version 2.0, remote software version Mocana SSH There's nothing we can do short of blacklisting every device reporting that version string and I'm not willing to do that without info from the vendor on what proportion of devices that might be. Please reopen if that information ever becomes available. Close all resolved bugs after 7.3p1 release |