mailing list archives
Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors
From: Chad Loder <cloder () loder us>
Date: Mon, 16 Dec 2002 09:18:27 -0800
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
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. :)
Rapid 7, Inc.
Full-Disclosure - We believe in it.