I'm disappointed that nobody has replied to my question. OpenSSH
development team, isn't the potential for a remote root exploit something
that's important to you? Many other tools that use zlib have issued a
public statement saying they are or they are not vulnerable.
- Dave
On Fri, Mar 22, 2002 at 12:37:35PM -0600, Dave Dykstra
wrote:> 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
> List-Post: <mailto:secureshell at securityfocus.com>
> List-Help: <mailto:secureshell-help at securityfocus.com>
> List-Unsubscribe: <mailto:secureshell-unsubscribe at
securityfocus.com>
> List-Subscribe: <mailto:secureshell-subscribe at securityfocus.com>
> Delivered-To: mailing list secureshell at securityfocus.com
> Delivered-To: moderator for secureshell at securityfocus.com
> 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 -----
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev