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

Message-ID: <Pine.LNX.4.42.0212161010160.1063-100000@nimue.bos.bindview.com>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: R7-0009: Vulnerabilities in SSH2 Implementations
 from Multiple Vendors

On Mon, 16 Dec 2002, Chad Loder wrote:

> The SSH.com and F-Secure issues are NULL pointer dereferences.

Righty-o :-)

My only point is, while there's a value in doing comprehensive research
like this - since you're testing a number of completely different
implementations, some of them very popular, some rather obscure - you
probably need to be specific just to serve the reader better, and
elliminate the risk of being accused of FUD. Consider Joe Admin who uses
SSH.com and reads your advisory.

There's no indication whatsoever as to the nature of problems spotted in
this particular implementation, so he assumes it suffers of one of the
vulnerability classes listed at the beginning of the advisory - remote
execution or DoS. You list his implementation as vulnerable in an advisory
that talks about those types of vulnerabilities, and later you quote the
vendor saying it is not an issue, with no commentary whatsoever. He is
confused. It takes time to find out.

> 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.

Your fault... No, really. An advisory is there to describe what you found.
You might want to suggest there are some other possibilities worth further
research - and you did that, good - but you shouldn't classify an
application as a whole as "confirmed vulnerable" to a specific security
issue based just on that. This is not how people are going to read it.
People are going to read it as "they tested application A and found it's
vulnerable to DoS or remote code execution; vendor denied; what's going
on?".

You have one good point, that is in some specific architectures, server
can be crashed by a NULL pointer dereference. But does this application
actually support such architectures? If yes, list specific architectures
on which this application is affected - especially since it is not going
to be affected on the majority of systems around.

I don't want to be a jackass, but I'm simply getting allergic to
advisories that do not help others - this is against the idea of full
disclosure, simple as that. I'm sorry if I am picking on the wrong
company, and once again, I'm not trying to discredit your research.

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