Is OpenSSH vulnerable to the ZLIB problem or isn't it?

Sat Mar 23 05:37:35 EST 2002

SSH.COM says their SSH2 is not vulnerable to the ZLIB problem even though
they use the library (details below).  Can OpenSSH say the same thing?

In either case, it seems like there ought to be an openssh-unix-announce
message about what the situation is.  I may have missed it, but I don't
believe there was one.  Yes, openssh doesn't have its own copy of zlib
source but it would still be helpful to have a statement, especially since
it appears under protocol 2 that it's potentially exploitable before
authentication.

- Dave Dykstra

----- Forwarded message from Erik Parker <eparker at mindsec.com> -----

Mailing-List: contact secureshell-help at securityfocus.com; run by ezmlm
Date: Wed, 20 Mar 2002 12:59:59 -0600 (CST)
From: Erik Parker <eparker at mindsec.com>
To: secureshell at securityfocus.com
Subject: RE: ZLIB.. WHere is SSH.COM?! Part 2 (fwd)

---------- Forwarded message ----------
Date: Mon, 18 Mar 2002 08:08:41 -0800
From: Thi Le <tle at ssh.com>
To: Erik Parker <eparker at mindsec.com>
Subject: RE: ZLIB.. WHere is SSH.COM?!

Dear Erik,

We sincerely apologize for the delay in responding to your question and concerns.

Below are the comments from our product management team:

There has been a vulnerability in zlib compression library that is being
used by SSH Secure Shell and numerous other applications and operating
systems.

SSH Secure Shell is NOT vulnerable to this thanks to our implementation
style.

Our software is using the vulnerable zlib library, but it can't be
exploited. If someone tries to perform an exploit only that specific
connection will crash. Not the server nor any other connections.

We will upgrade the zlib library in our future releases.

CERT and CERT-FI has been notified, no other reaction is necessary at this
point.

For further technical information, please see the technical explanation
below.

The problem works as follows: when a maliciously corrupted compressed
data stream is decompressed, it can cause the function
inflate_blocks() to enter a certain state and return FALSE.  If called
again in this state, this function can cause a heap corruption
exploitable by the attacker.  (More precisely, both the first and the
second call will attempt to free the same pointer.  This is layed out
in more detail in the advisory.)

We do not use the zlib directly.  Instead, we use a wrapper library
bufzip that is the only point in our code that is in directly contact
to the zlib.

The crucial point is this: if bufzip calls the misbehaving function in
the zlib, it always checks whether the return value is TRUE.  If not,
it terminates the process with a message that the compressed data
stream is corrupted.

Consequently, every attempt to attack makes the connection collapse
with a nasty error, which is exactly what we want if an attack is
going on.  No other effects are possible.

I hope that answers your question & concerns. Please feel free to contact
me if I can be of any further assistance.

Sincerely,
Thi Le
Eastern Region Territory Manager
SSH Communications Security

----- End forwarded message -----