full-disclosure - R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20021216171827.GB11420@loder.us>
From: cloder at loder.us (Chad Loder)
Subject: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors

> So, it seems to me that you found one less popular implementation that may
> be vulnerable to a remote code execution; another that is susceptible to
> DoS; and then you decided to throw SSH.com in just because you found a
> programming glitch (but not a security problem) in it, hoping that some
> people would read it as "there's a remote code execution problem in
> SSH.com" when the advisory is vague enough.
> 
> Don't get me wrong - I'm not saying you did that, and you did that on
> purpose.

It's really nothing so insidious as that.  :) F-Secure and SSH.com have
released detailed statements about the issue to CERT, which will show
up in CERT's advisory (not sure why it hasn't been released yet).  We
didn't want to duplicate all of the detailed vendor responses that
CERT is going to include in their vulnerability note.

The SSH.com and F-Secure issues are NULL pointer dereferences.  The
vendors have classified this as non exploitable, which we pointed
out clearly in the advisory.  A more detailed statement will be
released with the CERT vuln note.  In this case, we have not said
"This issue is definitely not exploitable."  Why?  Because we haven't
had time to run the test suite against earlier versions of these
products.  Because we have not adapted SSHredder to SSHv1 yet (which
we pointed out in the advisory).  Because we have not witnessed
the effects of the test suite on architectures without memory
protection (most router operating systems).  All this is caused
by limited access to a wide range of implementations, a limited time
to spend testing them, and limited answers to our questions from
many of the vendors.

To sum up, sorry if the advisory came off as too vague.  It was not
our intent to confuse anyone -- we are trying to strike a balance with
the length of our advisories, the amount of duplication between our
advisory and the CERT advisory/vuln note, etc.  Here's the key to
reading the advisory: anything without a note saying "Non
exploitable" is probably exploitable. :)

Yours,
	Chad Loder
	Rapid 7, Inc.