Connections from "OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006" to "OpenSSH_4.5p1, OpenSSL 0.9.8e 23 Feb 2007" using "aes256-ctr" fail with "Bad packet length". The same problem occurs when using PuTTY 0.59 against the newer server. PuTTY users have reported this problem too, with servers on both FreeBSD and Linux, and with OpenSSH versions back to 4.0. The problem occurs with the "aes256-ctr", "aes192-ctr", and "archfour256" ciphers, but not with "aes128-ctr", "aes256-cbc", "aes192-cbc", or "arcfour128".
Created attachment 1244 [details] debug messages from sshd On my test system, running NetBSD/macppc 2.1 and compiling with default settings (apart from directory prefixes), I get these log messages from the server.
Created attachment 1245 [details] client debug messages ... and these messages on the client.
It looks to me like the set of broken ciphers is precisely the set for which the key_len in the Cipher structure doesn't match that in the EVP. I suspect this is significant.
Between 0.9.8d and 0.9.8e, EVP_CIPHER_CTX_key_length changed from #define EVP_CIPHER_CTX_key_length(e) ((e)->key_len) to int EVP_CIPHER_CTX_key_length(const EVP_CIPHER_CTX *ctx) { return ctx->cipher->key_len; } so it seems that it's now returning the default key length of the cipher rather than that of the context. If I add a debug print of the key length you can see that it doesn't change even though EVP_CIPHER_CTX_set_key_length has been called: debug2: set_newkeys: mode 1 debug1: key len 16 debug2: cipher_init: set keylen (16 -> 32) debug1: key len 16 If I then change "return ctx->cipher->key_len" to "return ctx->key_len" in and recompile then everything seems to be peachy. So it would appear to be an OpenSSL bug. I'll file it upstream.
Created attachment 1246 [details] Work around openssl 0.9.8e bug in compat layer We can also work around this in the compat layer without too much trouble. Is this worth doing for the 4.6p1 release?
This bug bites with PuTTY's default configuration, so I expect we'd like it to go away ASAP to reduce the size of our mailboxes ;)
The OpenSSL folks confirmed the problem and that it's already been fixed in their CVS. So the remaining question is whether or not it's safe to apply the patch so close to release. I think it is since the patch is specific to the OpenSSL version that is known to have the problem. Damien? Tim?
Comment on attachment 1246 [details] Work around openssl 0.9.8e bug in compat layer >Index: openbsd-compat/openssl-compat.h >=================================================================== >RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/openssl-compat.h,v >retrieving revision 1.6 >diff -u -p -r1.6 openssl-compat.h >--- openbsd-compat/openssl-compat.h 22 Feb 2006 11:24:47 -0000 1.6 >+++ openbsd-compat/openssl-compat.h 4 Mar 2007 03:31:09 -0000 >@@ -46,6 +46,11 @@ extern const EVP_CIPHER *evp_acss(void); > # endif > #endif > >+/* OpenSSL 0.9.8e returns cipher key len not context key len */ >+#if (OPENSSL_VERSION_NUMBER == 0x0090805fL) >+# define EVP_CIPHER_CTX_key_length(c) ((c)->key_len) >+#endif Two question: 1. should there be a #undef here? 2. Have OpenSSL acknowledged that this is a bug? If not, perhaps this needs to run of a configure test?
(In reply to comment #8) > 1. should there be a #undef here? Not as long as it targets only 0.9.8e as EVP_CIPHER_CTX_key_length is a function not a macro in that version. > 2. Have OpenSSL acknowledged that this is a bug? Yes, I got a response from Lutz Jaenicke saying that my suggested change in comment #4 was correct and that it had already been applied to OpenSSL's CVS within the last week. > If not, perhaps this needs to run of a configure test? Maybe, but I would be concerned that it may interact something else in future. The proposed patch targets only the known problem version and is a no-op for every other version.
(In reply to comment #6) > This bug bites with PuTTY's default configuration, so I expect we'd > like it to go away ASAP to reduce the size of our mailboxes ;) Well then, in the interests of mailbox reduction (ours as well as yours :-) the patch has been committed and will be in 4.6p1. Thanks for the report.
Created attachment 1252 [details] key_len fix for Protocol 1 3des cipher Juan Gallego points out that this also affects the Protocol 1 3des cipher, which causes this: debug2: cipher_init: set keylen (16 -> 32) debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. This is what Corinna saw on Cygwin (http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-March/025179.html) but I got the wrong cipher in my suggested workaround.
The Cygwin bug also concerns 4.6 client connections to older Cisco devices, which use SSHv1/3des The patch in #11 fixes the problem here, thanks -- any chance for a 4.6p2 ?
We will probably make a release in the near future (~1.5 months), but I don't think this warrants rushing a portable release out the door sooner. I think you should be chasing the OpenSSL people to make a release, as this is completely their bug.
Close resolved bugs after release.