Announce: OpenSSH 4.6 released

[Darren Tucker]

Corinna Vinschen wrote:
> Hi,
> 
> On Mar  7 16:10, Damien Miller wrote:
>> OpenSSH 4.6 has just been released. It will be available from the
>> mirrors listed at http://www.openssh.com/ shortly.
>>
>> OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
>> implementation and includes sftp client and server support.
> 
> A user on the Cygwin mailing list found a problem with 4.6p1 when
> using protocol version 1.  The bug report was rather short:
> 
> $ ssh -1 somemachine
> Disconnecting: Corrupted check bytes on input.
> 
> I can reproduce this behaviour and when starting ssh with -vvv flags,
> the above error message is printed in this context:
> 
>   debug1: Found key in /home/corinna/.ssh/known_hosts:221
>   debug1: Encryption type: 3des
>   debug1: Sent encrypted session key.
>   debug2: cipher_init: set keylen (16 -> 32)
>   debug2: cipher_init: set keylen (16 -> 32)
>   debug1: Installing crc compensation attack detector.
>   Disconnecting: Corrupted check bytes on input.
> 
> The problem is that only the Cygwin 4.6p1 version seems to be affect.
> 
> I tested the following combinations, the rows are the ssh version
> with which I tried to connect to the sshd versions in the columns,
> always with version 1.5 protocol.
> 
>     sshd:   Linux 4.5    Linux 4.6    Cygwin 4.5    Cygwin 4.6
> ssh:
> Linux 4.5     ok            ok            ok        corrupted
> Linux 4.6     ok            ok            ok        corrupted
> Cygwin 4.5    ok            ok            ok        corrupted
> Cygwin 4.6  corrupted    corrupted    corrupted         ok
> 
> Apparently it doesn't have anything to do with the last minute patch I
> sent to this list a couple of days ago.  It doesn't matter whether I use
> text read/write, or text read/binary write, or binary read/write.
> The effect is always the same.  Since the checksums are transmitted
> using sockets, and sockets are unconditionally using binary read/write
> mode anyway, this was not to be expected.
> 
> So, my question is this:  Is there any change in the protocol 1 code
> which could explain this behaviour?  Where shall I look if I try to
> debug this further?  I'm rather a bit stumped right now.

If you're using OpenSSL 0.9.8e you could try backing out this bit in
openbsd-compat/openssl-compat.h:

/* 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

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.