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 rootat_private If for some reason you can't access the attachments, you can find copies of them on my web site at the following URL: http://www.digitaloffense.net/openssh_zlib/
This archive was generated by hypermail 2b30 : Tue Mar 12 2002 - 14:14:00 PST
