Full Disclosure mailing list archives
Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors
From: Michal Zalewski <lcamtuf () ghettot org>
Date: Mon, 16 Dec 2002 08:56:27 -0800 (PST)
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 -- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors Rapid 7 Security Advisories (Dec 16)
- Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors Michal Zalewski (Dec 16)
- <Possible follow-ups>
- Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors Chad Loder (Dec 16)
- Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors Michal Zalewski (Dec 16)
- Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors matt merhar (Dec 16)
- Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors Knud Erik Højgaard (Dec 16)
- Re: R7-0009: Vulnerabilities in SSH2 Implementations from Multiple Vendors Michal Zalewski (Dec 16)