[rootshell] Security Bulletin #25

Well, seeing how 2.0 is actually a commercial product and supposedly
re-written, I can see why they'd want to sell it. If you want to run ssh
and don't want to pay for it, you're stuck with the 1.x version. Those
that can pay do, and those that don't whine for some reason. It's not
like you couldn't take the source to 1.2.26 and alter it now, is it?

Have you ever stopped to look at the src to 2.0? Large portions of it is
unfinished. Hell the only symetric ciphers they have are DES (do we even
have to go here), RC4 (a stream cipher that has been implimented wrong in
SSH before), and Mars (an AES candidate from IBM which has known attacks
against it).

We plopped v1.2.21 into production over a year (Aug97) ago. We use the
F-secure WinNT client. We have not seen compelling reason to upgrade.
Insignificat additional features and huge risk that our WinNT clients would
also have to be upgraded. I am not aware of published exploits against this
version, or higher, of SSH.

We have been watching more recent version have their problems. Recently it
has been the 2.x series. We feel quite justified in using what works, in

Right. The kicker for me has been that i can't get a V1 client to work with
V2 sshd (and BTW i can't get a V2 client to work with V1 sshd). So this
would mean a wholesale upgrade of all clients, including Windex ones...

Joe Loiacono Phone: (301) 794-2509
Computer Sciences Corporation Fax: (301) 794-9530

We've currently got F-secure WinNT client v1.1 installed on our PCs.
We also have both ssh V1 and V2 installed on Unix servers. The V2
sshd recognizes V1 connections and passes them off to the V1 sshd.
The trick I had to stumble on is that you have to have both V1 sshd
and V2 sshd installed, with V2 sshd running as the default ssh.

Connections from a V2 ssh likewise will pass the outgoing connection
off to the V1 ssh if the remote server is a V1 server. Again, you
have to have both V1 and V2 clients installed to make this work.


I just got this. MHSC is also on the SSH mailer-list. It looks as if ALL
accusations of SSH being exploitable are thinly founded at best.

Date: Mon, 2 Nov 1998 11:45:53 +0200 (EET)
From: Tatu Ylonen <ylo@ssh.fi>
To: ssh@clinet.fi, info@rootshell.com
Subject: Important information about IBM-ERS's "ssh" advisory (fwd)
Message-ID: <Pine.OSF.4.05.9811021143180.19300-100000@torni.ssh.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ssh@clinet.fi
Precedence: bulk
X-UIDL: a3533f8bef2d09b2dd5c56b653ba57e1

Please find enclosed a copy of a message from the IBM Emergency response


SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ipsec.com/
Free Unix SSH What is the Secure Shell (SSH) Protocol? | SSH Academy

Date: Mon, 02 Nov 1998 04:15:28 EST

From: David A. Curry <davy@ers.ibm.com>
To: bugtraq@netspace.org, first-info@first.org, first-teams@first.org,
Subject: Important information about IBM-ERS's "ssh" advisory


On Friday, Oct. 30th, IBM-ERS sent out a draft advisory to be released on
Monday, Nov. 2nd that described a buffer overflow condition in Version
1.2.x "sshd." This draft was sent to the Forum of Incident Response and
Security Teams, and also to the "ssh-bugs" list for their comment/review.
The draft was identified as ERS-SVA-E01-1998:005.1.

Rootshell has unfortunately chosen to include a copy of this draft advisory
in their recent newsletter, apparently for the purposes of defending itself
against charges that it was unfairly disparaging "sshd." Use of IBM-ERS's
draft advisory in this manner was not approved or authorized by IBM-ERS,
and does a disservice to all.

Here are the facts about this advisory:

1. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was never issued publicly by

2. In response to a telephone query from Kit Knox of Rootshell, IBM-ERS
  attempted to contact Kit on Friday evening, and was unable to reach
  him. Specific contact information for IBM-ERS, as well as a brief
  status update, were left on Mr. Knox's voice mail. Mr. Knox never
  contacted IBM-ERS after that time.

3. IBM has been working closely with Tatu Ylonen, author of "ssh," to make
  sure that the potential vulnerability described in the advisory is not
  exploitable. Upon further investigation, the problem originally
  described appears to have been influenced by outside factors and does
  not appear to be an exploitable problem in "sshd."
4. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was CANCELLED on the morning
  of Sunday, Nov. 1st, *before* Mr. Knox issued his newsletter.

5. At this time, IBM-ERS has NO KNOWLEDGE of any security vulnerabilities,
  exploitable or otherwise, in the "sshd" program.

We hope that this clarifies IBM's involvement in this situation.

- ---------------------------------------------------------------------------

The information in this document is provided as a service to customers of
the IBM Emergency Response Service. Neither International Business Machines
Corporation, nor any of its employees, makes any warranty, express or


or assumes any legal liability or responsibility for the accuracy, complete-
ness, or usefulness of any information, apparatus, product, or process
contained herein, or represents that its use would not infringe any privately
owned rights. Reference herein to any specific commercial products, process,

or service by trade name, trademark, manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation or favoring

by IBM or its subsidiaries. The views and opinions of authors expressed
herein do not necessarily state or reflect those of IBM or its subsidiaries,
and may not be used for advertising or product endorsement purposes.

Version: 2.7.1


and then found this.

To: runge@crl.com
CC: ssh@clinet.fi
Subject: Re: ssh 1.2.26 and root compromise


Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ssh@clinet.fi
Precedence: bulk
X-UIDL: 82af265d49d9ab5f1da6706787093894

Karl J. Runge wrote:

Maybe. I see about 125 calls to log_msg() in the ssh 1.2.x source code.
Does anyone see one (or more?) calls that might be passing unprotected
strings? I assume the unlimited %s are the place to start...
[info: IBM's announcement points us to log_msg() as the source
of the buffer overrun, but does not say which one. See rootshell
statement which has the IBM announcement]

I doubt the logging of "log_msg" has to do with the use of the word
"log", but the IBM announcement is dated 10/30 ... (I just saw it today
for the first time).

The IBM advisory was cancelled within 24 hours. The appearent buffer
overflow IBM found was not reproducable on any other systems, and
appearently was due to some local problem with the Linux installation on
one particular machine. See