Subject: exploiting the zlib bug in openssh
From: H D Moore <sflist@digitaloffense.net>
To: bugtraq@securityfocus.com, vulnwatch@vulnwatch.org
 
A bug was found in the zlib compression library which causes inflateEnd() to 
incorrectly free the same chunk of memory twice when given a deformed chunk 
of compressed data. A PNG image was discovered  (not by me) which triggers 
this flaw, it is attached. 

OpenSSH uses the zlib library to compress data when the -C option is passed 
to it. With version 2 of the protocol, it is possible to send 
compressed/encrypted messages to the remote daemon before having to 
authenticate (just after key exchange). This is done using SSH2_MSG_IGNORE 
packets in the kex2() function of sshconnect2.c.

The attached patch to libpng-1.2.1 causes pngtest to dump out the contents of 
the buffer it passes to inflate(). This is used with the attached PNG file to 
obtain the buffer the OpenSSH client needs to send. The buffer size has been 
tweaked in libpng to match the one used in OpenSSH-3.1p1 (4096 bytes). The 
pngtest program will SEGV after dumping out this buffer from the PNG file.

I patched the OpenSSH client to send this corrupt zlib buffer after the key 
exchange, the inflate() call on the remote end is returning the correct value 
indicating that the buffer did what it was supposed to (Z_MEM_ERR or -4), but 
the remote daemon is NOT crashing during the fatal_cleanup() and inflateEnd() 
calls.  Taking the same buffer and sticking it into the inflate() call of 
another application causes the desired SEGV and possible path to 
exploitability, so why isn't OpenSSH crashing?

The attached patch applies to OpenSSH-3.1p1, if you run the daemon code it 
will spit out the recieved buffer (to make sure it made it across ok) and 
some other debugging information. The recommended command line to test this:

# ./sshd -d -d -d
# ./ssh -2 -C -v -v -v root@127.0.0.1