> From: owner-openssl-us...@openssl.org On Behalf Of Johansen Daniel > Sent: Friday, 27 April, 2012 03:18
> Im sorry for removing some "sensitive" information, but it is > company policy. > Understood. > SFTP Server is using maverick sshd library (java based). > I haven't used that myself, but on a quick browse of the website it looks pretty good. In any case, your Wireshark clears it of the suspicion of sending a bad or misencoded group (below). > Wireshark Output: > > Following is Packet no. 264 > -------------------------------------------------------------- > -------------- > SSH Protocol > SSH Version 2 (encryption:aes128-cbc mac:hmac-sha1 > compression:none) > Packet Length: 148 > Padding Length: 8 > Key Exchange > Msg code: Diffie-Hellman Key Exchange Reply (31) > Multi Precision Integer Length: 129 > DH modulus (P): > 00ffffffffffffffffc90fdaa22168c234c4c6628b80dc1c... Okay, that is a correctly encoded 1024-bit mpint. And probably the Oakley modp1024 adopted by SSH as group1, which is definitely a valid group, and a convenient one. So the client program is mistaken to complain about it. In the output you posted it claims to be (and certainly behaves like) OpenSSH-5.9p1 using OpenSSL 1.0.1, which I would not expect to have a bug this bad, although conceivably it's a bad build (or patch). See below. > Multi Precision Integer Length: 1 > DH base (G): 02 > Padding String: da7d2dba194ca285 > -------------------------------------------------------------- > -------------- > > No. Time Source Destination > Protocol Length Info > 260 117.341377 <SERVER> <CLIENT> TCP > 54 EtherNet-IP-1 > 43161 [ACK] Seq=322 Ack=838 Win=7424 Len=0 > 264 117.491396 <SERVER> <CLIENT> SSHv2 > 206 Server: Diffie-Hellman Key Exchange Reply > 265 117.509038 <CLIENT> <SERVER> TCP > 60 43161 > EtherNet-IP-1 [ACK] Seq=838 Ack=474 Win=8064 Len=0 > 266 117.509231 <CLIENT> <SERVER> TCP > 60 43161 > EtherNet-IP-1 [FIN, ACK] Seq=838 Ack=474 Win=8064 Len=0 > 267 117.509292 <SERVER> <CLIENT> TCP > 54 EtherNet-IP-1 > 43161 [FIN, ACK] Seq=474 Ack=839 Win=7424 Len=0 > 272 117.527293 <CLIENT> <SERVER> TCP > 60 43161 > EtherNet-IP-1 [ACK] Seq=839 Ack=475 Win=8064 Len=0 > That is indeed normal client-initiated shutdown. Looking at the source for 5.9p1, dhgexc.c calls fatal for this case, which calls cleanup_exit, which apparently calls _exit, which (on Unix) is consistent with this. Looking further at the source, the line I was worried about, "Couldn't read packet: connection reset by peer" is actually something else. I didn't realize OpenSSH sftp-client uses a separate ssh-client process for transport, via either pipes or AF_UNIX sockets. When ssh-client suicides, sftp-client apparently gets "reset", but it isn't on the ssh connection so it isn't relevant to your problem. Since the client program is wrong here, that's what now must be investigated. If the client user can try another program(s) (version(s) or maybe system(s)) that's probably the easiest first step. If they need to use the program(s) that are affected, it looks to me like either they need to debug it, or give it to you to debug. In either case if it isn't a debug build, debugging will be more difficult; and for bugs like this (in C programs) changing to debug build by itself may alter and even "cure" the symptoms. At minimum they (or you) need to know what source it was built from (standard or patched/modified) and how. If someone does debug it, the first thing I would check is the 'bits' table used in BN_num_bits_word called from (but in my to-hand linux build inlined into) BN_num_bits. If that table is clobbered (as could happen for a C bug involving a bad pointer or buffer overrun) or not accessed correctly (perhaps a bad build, or some incompatibility or mistake in .so/etc loading), it could throw off num_bits without any actual bad code anywhere. The actual sftp->ssh exec passes numerous arguments, but I think most aren't relevant here. To simplify debugging try ssh -vvv -p<port> -l<user> -s <host> sftp </dev/null and see if that gets the same error and if so debug that, rather than the more complicated multiprocess setup. Good luck. This looks like a nasty one. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
