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-prev] [day] [month] [year] [list]

From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: R7-0009: Vulnerabilities in SSH2 Implementations
 from Multiple Vendors

On Mon, 16 Dec 2002, Rapid 7 Security Advisories wrote:

>   [...] denial-of-service attacks and/or arbitrary code execution [...]
>   While the impact is different for each product tested, some of
>   these errors were easily exploitable, allowing the attacker to
>   overwrite the stack pointer with arbitrary data.

Why didn't you provide a specific impact information for each
implementation listed as affected? The most popular of affected
implementations you have on your list is SSH.com, yet you say "SSH, Inc.
has characterized this issue as not exploitable" and you do not elaborate.

Are they wrong? Or are they right? If they're right, why is their product
in a "vulnerable" section of an advisory that describes "denial-of-service
attacks and/or arbitrary code execution" vulnerabilities? It may segfault,
but is there an actual security exposure that could be, even remotely,
classified as one of the above vulnerability classes?

I'm curious because I had a pleasure to deal with SSH.com authors in the
past, and I have a reason to believe they're fairly reasonable and
open-minded in admitting even a potential problem. I wouldn't expect them
to fight and claim the issue is not exploitable if you suggested even a
very unlikely and incomplete attack scenario - and not without a reason,
many vendors got burned denying or downplaying such issues, and only some
can still afford it - small companies focused on security generally can't.

I, and many many other people, tried to fuzz major SSH implementations one
way or another. The problem - just a guess - affected SSH.com in your
tests is a bunch of NULL pointer conditions in the kexinit routines - not
exploitable as a DoS, because only the child process is affected, not
exploitable as remote code execution neither. I haven't used your tool,
but this seems to be a good possibility. The location is matching, those
problems can be found after 5 minutes of fuzzing SSHv2, but are not
present in SSHv1, SSH.com is affected, OpenSSH isn't, this is a memory
violation problem, and you say that most of the issues you've found are
"memory access violations". Why this wasn't reported is that it is fairly
obvious that there are no serious security implications.

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. I'm not even saying I have to be right in guessing what the
problem is. But because your advisory is vague in identifying the exposure
for each implementation, it looks suspicious.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2002-12-16 08:21 --