6775914 2001-07-20 17:34 -0700 /170 rader/ Stephanie Thomas <customer.service@ssh.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-21 02:53 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18237>
Ärende: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Stephanie Thomas" <customer.service@ssh.com>
To: <bugtraq@securityfocus.com>
Message-ID: <FNEKKFMHLBAMAHPEHBLMCEAGCAAA.customer.service@ssh.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Secure Shell Community,
A potential remote root exploit has been discovered
in SSH Secure Shell 3.0.0, for Unix only, concerning
accounts with password fields consisting of two or
fewer characters. Unauthorized users could potentially
log in to these accounts using any password, including
an empty password. This affects SSH Secure Shell 3.0.0
for Unix only. This is a problem with password
authentication to the sshd2 daemon. The SSH Secure
Shell client binaries (located by default in
/usr/local/bin) are not affected.
SSH Secure Shell 3.0.1 fixes this problem.
Please note that if using a form of authentication
other than password, AND password authentication
is disabled, you are NOT VULNERABLE to this issue.
PLATFORMS IMPACTED:
Red Hat Linux 6.1 thru 7.1
Solaris 2.6 thru 2.8
HP-UX 10.20
HP-UX 11.00
Caldera Linux 2.4
Suse Linux 6.4 thru 7.0
Please note that other platforms not listed here
may also be vulnerable.
PLATFORMS NOT IMPACTED:
Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable.
Please note that other platforms not listed here
may also be immune.
SCOPE
Some stock machines which have default locked accounts
running SSH Secure Shell 3.0 are vulnerable to
arbitrary logins. This is a serious problem with
Solaris, for example, which uses the sequence "NP" to
indicate locked administrative accounts such as "lp",
"adm", "bin" etc. Some Linux machines which have
accounts with !! in the etc/passwd or /etc/shadow such
as xfs or gdm are also vulnerable. Since it is relatively
easy to become root after gaining access to certain
accounts, we consider this a potential root exploit.
DETAILED DESCRIPTION
During password authentication, if the field containing
the encrypted password in /etc/shadow, /etc/password,
etc. is two or less characters long, SSH 3.0.0 will
allow anyone to access that account with ANY password.
The bug is in the code that compares the result of calling
crypt(pw, salt) with the value of the encrypted password
in the /etc/shadow (or /etc/password) file. SSH Secure Shell
Server 3.0.0 does a bounded string compare bounded to the
length of the value stored in aforementioned file (2
characters in this case) against the return value of
crypt(). The return value of crypt() is 13 characters,
with the first two characters being the salt value itself.
The salt value used is the first two characters of the
encrypted password in /etc/shadow (or /etc/password). A
2 character string comparison between the 2 character
encrypted password in /etc/shadow, and the 13 character
crypt() return value, whose first two characters ARE the
2 characters from the password in /etc/shadow. The strings
match, and the 3.0.0 daemon then accepts the password, no
matter what is input.
SOLUTIONS
Preferred
Immediately upgrade to SSH Secure Shell 3.0.1
which will be available on our e-commerce site
http://commerce.ssh.com shortly, and is available
on the ftp site now - ftp://ftp.ssh.com/pub/ssh
A patch for 3.0.0 source code is also available there.
Alternative work-arounds
Disable password authentication to the SSH Secure Shell
daemon (sshd2) in the /etc/ssh2/sshd2_config and use
another form of authentication such as public key,
SecurID, Kerberos, certificates, Smart Cards, or
hostbased to authenticate your users. These alternative
authentication methods are NOT VULNERABLE. Please see
our SSH Secure Shell support web pages for more
information on how to enable these authentication methods.
OR
If you cannot disable password authentication fully,
limit access to the sshd2 daemon to allow only users
with entries in the /etc/passwd and /etc/shadow which
exceed two characters. This can be done using the
AllowUsers, AllowGroups, DenyUsers, and DenyGroups
keywords in the /etc/ssh2/sshd2_config file. See
our SSH Secure Shell support web pages
http://www.ssh.com/support/ssh and man sshd2_config
for more information.
OR
Assign a valid password for each account. Because
it is possible that assigning a password to some
system accounts could cause problems on some operating
systems, this work-around is limited and is provided
only as a last-resort alternative.
OR
Use the following patch in the source code:
"""
File /lib/sshsession/sshunixuser.c
Function ssh_user_validate_local_password
Location near line 953, before
/*Authentication is accepted if the encrypted
passwords are identical. */
Add lines
if (strlen(correct_passwd) < 13)
return FALSE;
""
We apologize for any inconvenience this may cause.
SSH Communications Security takes security issues very
seriously, and a CERT advisory and submission to Bugtraq
regarding this issue have been submitted. Please make
every effort to ensure that your systems are protected
using one of the above methods as quickly as possible.
As this information becomes widely known, your systems could
be at even greater risk if appropriate measures are not taken.
SSH is fully committed to serving and supporting our users
and products. While we may not be able to address each request
for information on this issue individually, we will
make publicly available any relevant information possible
which addresses your questions and concerns.
CREDITS
This vulnerability was found and reported by an
anonymous system administrator at the Helsinki University
of Technology and by Andrew Newman of Yale University.
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.1
iQA/AwUBO1jNq9BQTPJLnwPSEQKmMQCeIOd7B30wubtA3p3hrAK61dZhn08AoIx+
kAzWH6o/mdL81W9TC4tJINgp
=2BQq
-----END PGP SIGNATURE-----
(6775914) /Stephanie Thomas <customer.service@ssh.com>/
Kommentar i text 6776002 av Dan Kaminsky <dankamin@cisco.com>
Kommentar i text 6777835 av Michal Zalewski <lcamtuf@gis.net>
Kommentar i text 6779326 av Jen B. <jen@sedition.org>
Kommentar i text 6779327 av Marcus Meissner <mm@ns.caldera.de>
Kommentar i text 6785045 av Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Kommentar i text 6785767 av Marcin Zurakowski <marcin@interfirma.pl>
Kommentar i text 6786240 av Jaime BENJUMEA <benjumea@dte.us.es>
Kommentar i text 6786276 av Roman Drahtmueller <draht@suse.de>
6776002 2001-07-20 19:11 -0700 /51 rader/ Dan Kaminsky <dankamin@cisco.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-21 05:07 av Brevbäraren
Extern mottagare: Stephanie Thomas <customer.service@ssh.com>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18238>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Dan Kaminsky" <dankamin@cisco.com>
To: "Stephanie Thomas" <customer.service@ssh.com>,
<bugtraq@securityfocus.com>
Message-ID: <007b01c1118a$64bb2570$1900010a@na.cisco.com>
> Some stock machines which have default locked accounts
> running SSH Secure Shell 3.0 are vulnerable to
> arbitrary logins. This is a serious problem with
> Solaris, for example, which uses the sequence "NP" to
> indicate locked administrative accounts such as "lp",
> "adm", "bin" etc. Some Linux machines which have
> accounts with !! in the etc/passwd or /etc/shadow such
> as xfs or gdm are also vulnerable. Since it is relatively
> easy to become root after gaining access to certain
> accounts, we consider this a potential root exploit.
Since on Solaris all the standard binaries(sh, ls, rm, etc.) are bin
owned, all systems with SSH-3.0 should be considered to be completely
rootable by even basic unix-aware attackers. Worse, the nature of
the SSH protocols is that the exact version of the SSH server shows
up upon initial connection to the SSHD port. This means a mass scan,
combined perhaps with minor TCP property analysis, will reveal both
the vulnerable SSHD and the specific OS whose accounts are to be
attacked.
Mass SSH scanners are available; it may be worthwhile as an
administrator to search and cleanse your network before someone else
does. While you're at it, watch for OpenSSH 2.2.0p2 in particular,
as there apparently exist Linux root exploits for that obscure
deattack.c bug found several months ago.
The big issue here, of course, is not that sshd incorrectly checks
the cryptographic hash of an inadequately sized password but that it
checks it at all. NP, as far as I know, specifically stands for No
Password (acceptable, *not* needed), and !! I believe has the same
meaning for Linux(! for "no"). SSHD has traditionally when possible
directly tested its passwords straight through most available
interfaces, be them a raw password file or a PAM call. But when the
SSHD checked the cryptography of NP or !!, it failed to successfully
parse the critical message in the password database: Let Nothing At
All, No Matter What, In.
When such a message exists, it deserves immediate servicing. They
expected the cryptography to fail; it was an implicit assumption that
an explicit security-critical demand would be serviced automatically.
The assumption was incorrect, and now a reasonably major hole exists.
Yours Truly,
Dan Kaminsky, CISSP
http://www.doxpara.com
(6776002) /Dan Kaminsky <dankamin@cisco.com>/(Ombruten)
Kommentar i text 6778712 av Dale Southard <southard1@llnl.gov>
Kommentar i text 6785928 av Brandon S. Allbery KF8NH <allbery@ece.cmu.edu>
6778712 2001-07-21 13:50 -0700 /48 rader/ Dale Southard <southard1@llnl.gov>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-21 23:32 av Brevbäraren
Extern mottagare: Dan Kaminsky <dankamin@cisco.com>
Extern kopiemottagare: Stephanie Thomas <customer.service@ssh.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18240>
Kommentar till text 6776002 av Dan Kaminsky <dankamin@cisco.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Dale Southard <southard1@llnl.gov>
To: "Dan Kaminsky" <dankamin@cisco.com>
Cc: "Stephanie Thomas" <customer.service@ssh.com>,
<bugtraq@securityfocus.com>
Message-ID: <n15y80rn.fsf@riptide.llnl.gov>
"Dan Kaminsky" <dankamin@cisco.com> writes:
> The big issue here, of course, is not that sshd incorrectly checks the
> cryptographic hash of an inadequately sized password but that it checks it
> at all. NP, as far as I know, specifically stands for No Password
> (acceptable, *not* needed), and !! I believe has the same meaning for
> Linux(! for "no").
Actually, I don't think it is nearly that complex...
On systems that use the standard unix crypt(), that function always
returns a 13 character string (a 2 character salt followed by an 11
character hash). When a user tries to login, the system gets the 2
character salt from the password file and a password from the user,
and then runs those through crypt() and compares the 13 character
result to the hash string in the password file. If they match, he/she
is authenticated.
Things like ``!!'', ``NP'', ``*LK*'' in the password file do not need
to have to have any special meaning to the OS other than the fact that
they are not 13 characters and thus will never match the output of
crypt().
Sshd should probably be constraining its match to the length of the
crypt() output rather than the length of the password file entry. [I
say ``probably'' here because some systems (AIX) seem to produce null
password file hashes when `passwd` is given a null password. If that
behavior is due to the underlying crypt() function, then the
``probably'' suggestion I just made yields remote root on those
systems.]
Systems that use md5 or blowfish for password hashing do something
different. :-) :-)
--
/* Dale Southard Jr. southard1@llnl.gov 925-422-1463 */
/* Computer Scientist, Accelerated Strategic Computing Initiative */
/* L-550, Lawrence Livermore National Lab, Livermore CA 94551 */
/* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
(6778712) /Dale Southard <southard1@llnl.gov>/------
Kommentar i text 6785329 av Nate Eldredge <neldredge@hmc.edu>
6785329 2001-07-22 06:14 -0700 /29 rader/ Nate Eldredge <neldredge@hmc.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 19:22 av Brevbäraren
Extern mottagare: Dale Southard <southard1@llnl.gov>
Extern kopiemottagare: Dan Kaminsky <dankamin@cisco.com>
Extern kopiemottagare: Stephanie Thomas <customer.service@ssh.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18253>
Kommentar till text 6778712 av Dale Southard <southard1@llnl.gov>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Nate Eldredge <neldredge@hmc.edu>
To: Dale Southard <southard1@llnl.gov>
Cc: Dan Kaminsky <dankamin@cisco.com>,
Stephanie Thomas <customer.service@ssh.com>,
bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0107220554010.24934-100000@odin.ac.hmc.edu>
On 21 Jul 2001, Dale Southard wrote:
> Sshd should probably be constraining its match to the length of the
> crypt() output rather than the length of the password file entry. [I
> say ``probably'' here because some systems (AIX) seem to produce null
> password file hashes when `passwd` is given a null password. If that
> behavior is due to the underlying crypt() function, then the
> ``probably'' suggestion I just made yields remote root on those
> systems.]
What's wrong with just using `strcmp' (i.e. no constraint at all)?
After all, what you want to know is just whether the two strings are
identical, period. And unless crypt() and /etc/shadow are both
broken, it will stop at the right place. I realize it goes against
the reflexive "only strn* functions are safe" idea, but that
shouldn't substitute for thinking...
--
Nate Eldredge
neldredge@hmc.edu
(6785329) /Nate Eldredge <neldredge@hmc.edu>/(Ombruten)
6785928 2001-07-20 23:08 -0400 /27 rader/ Brandon S. Allbery KF8NH <allbery@ece.cmu.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 21:06 av Brevbäraren
Extern mottagare: Dan Kaminsky <dankamin@cisco.com>
Extern mottagare: Stephanie Thomas <customer.service@ssh.com>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18263>
Kommentar till text 6776002 av Dan Kaminsky <dankamin@cisco.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu>
To: Dan Kaminsky <dankamin@cisco.com>,
Stephanie Thomas <customer.service@ssh.com>,
bugtraq@securityfocus.com
Message-ID: <70920000.995684910@vpn88.ece.cmu.edu>
On Friday, July 20, 2001 19:11:02 -0700, Dan Kaminsky
<dankamin@cisco.com> wrote:
+-----
| The big issue here, of course, is not that sshd incorrectly checks the
| cryptographic hash of an inadequately sized password but that it checks it
| at all. NP, as far as I know, specifically stands for No Password
| (acceptable, *not* needed), and !! I believe has the same meaning for
| Linux(! for "no"). SSHD has traditionally when possible directly tested
+--->8
Is it me, or is this the *same* bug that was found in the 1.2.x code
some time back?
--
brandon s. allbery [os/2][linux][solaris][freebsd] allbery@kf8nh.apk.net
system administrator [JAPH][WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [linux: proof of the million monkeys theory]
(6785928) /Brandon S. Allbery KF8NH <allbery@ece.cmu.edu>/(Ombruten)
6777835 2001-07-21 11:16 -0400 /22 rader/ Michal Zalewski <lcamtuf@gis.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-21 19:21 av Brevbäraren
Extern mottagare: Stephanie Thomas <customer.service@ssh.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18239>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@gis.net>
To: Stephanie Thomas <customer.service@ssh.com>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0107211106280.785-100000@nimue.bos.bindview.com>
On Fri, 20 Jul 2001, Stephanie Thomas wrote:
> PLATFORMS IMPACTED: Red Hat Linux 6.1 thru 7.1
RedHat Linux 7.0 ships OpenSSH 2.2.1 (7.0). RedHat Linux 7.1 ships
OpenSSH 2.5.2. Previous versions shipped SSH 1.2.xx, which, if I
understood, are not vulnerable. You are vulnerable only if you have
installed SSH.com SSH 3.0.0 by hand, but then, it is not RedHat fault.
--
_____________________________________________________
Michal Zalewski [lcamtuf@bos.bindview.com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
(6777835) /Michal Zalewski <lcamtuf@gis.net>/(Ombruten)
Kommentar i text 6779304 av <j@jedi.claranet.fr>
Kommentar i text 6785830 av Trond Eivind Glomsrød <teg@redhat.com>
6779304 2001-07-21 18:27 +0000 /21 rader/ <j@jedi.claranet.fr>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-22 06:15 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Stephanie Thomas <customer.service@ssh.com>
Mottagare: Bugtraq (import) <18241>
Kommentar till text 6777835 av Michal Zalewski <lcamtuf@gis.net>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: j@jedi.claranet.fr
To: bugtraq@securityfocus.com
Cc: Stephanie Thomas <customer.service@ssh.com>
Message-ID: <20010721182701.5D205D99E@mail.fr.clara.net>
Michal Zalewski wrote:
> You are vulnerable only if you have installed SSH.com SSH
> 3.0.0 by hand, but then, it is not RedHat fault.
Same thing with SuSE.
No version of SuSE Linux comes with SSH 3.0 as far as I know.
--
Frank DENIS aka Jedi/Sector One <j@c9x.org>
Upgrade your FTP server to something simple and secure :
http://www.pureftpd.org - http://metalog.sourceforge.net
(6779304) / <j@jedi.claranet.fr>/-------------------
6785830 2001-07-21 17:00 -0400 /22 rader/ Trond Eivind Glomsrød <teg@redhat.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 20:52 av Brevbäraren
Extern mottagare: Michal Zalewski <lcamtuf@gis.net>
Extern kopiemottagare: Stephanie Thomas <customer.service@ssh.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18260>
Kommentar till text 6777835 av Michal Zalewski <lcamtuf@gis.net>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: teg@redhat.com (Trond Eivind Glomsrød)
To: Michal Zalewski <lcamtuf@gis.net>
Cc: Stephanie Thomas <customer.service@ssh.com>,
bugtraq@securityfocus.com
Message-ID: <xuyae1ym1z6.fsf@halden.devel.redhat.com>
Michal Zalewski <lcamtuf@gis.net> writes:
> On Fri, 20 Jul 2001, Stephanie Thomas wrote:
>
> > PLATFORMS IMPACTED: Red Hat Linux 6.1 thru 7.1
>
> RedHat Linux 7.0 ships OpenSSH 2.2.1 (7.0). RedHat Linux 7.1 ships OpenSSH
> 2.5.2. Previous versions shipped SSH 1.2.xx
Releases of Red Hat Linux earlier than RHL 7 didn't ship openssh or
ssh at all.
--
Trond Eivind Glomsrød
Red Hat, Inc.
(6785830) /Trond Eivind Glomsrød <teg@redhat.com>/(Ombruten)
6779326 2001-07-21 04:47 -0400 /67 rader/ Jen B. <jen@sedition.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-22 06:52 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18243>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Jen B." <jen@sedition.org>
To: bugtraq@securityfocus.com
Message-ID: <Pine.BSF.4.21.0107210427120.59077-100000@puck.rageandfury.com>
<from SSH's advisory>
> in SSH Secure Shell 3.0.0, for Unix only, concerning
> accounts with password fields consisting of two or
> fewer characters.
I've tested this on a few machines that I recently upgraded
and have a nit to pick the "or fewer" portion of this statement.
It's quite late here and I feel I am stating the elementary,
further comments and corrections would be very helpful.
On RH 6.2 some of the password fields are
nulled in /etc/shadow with "*" and some with "!!"
The only accounts vulnerable to this bug were the ones using "!!"
or any other two-character combinations that I tried. I replaced
the offending accounts with a single character and was unable to login
with the "ease" that I had before. I tested on Debian 2.2 and
RedHat 6.2. It is worth noting that Debian does NOT null logins in
/etc/shadow using two characters by default like Red Hat.
btw, I also tested on FreeBSD-4.2 and was unable to login
without providing the proper password regardless of the number of
characters I had in the password field.
-Jen
jen@sedition.org
debian:~# telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-3.0.0 SSH Secure Shell (non-commercial)
Connection closed by foreign host. debian:~# uname -a Linux debian
2.4.6-pre3 #4 SMP Tue Jun 26 12:34:37 EST 2001 ppc unknown debian:~#
cat /etc/shadow | grep irc irc:!!:11498:0:99999:7::: debian:~# ssh -l
irc localhost irc's password: Authentication successful. Last login:
Sat Jul 21 2001 01:44:01 -0500 No mail. irc@debian:~$ debian:~# vi
/etc/shadow ... debian:~# cat /etc/shadow | grep irc
irc:!:11498:0:99999:7::: debian:~# ssh -l irc localhost irc's
password: irc's password: irc's password: warning: Authentication
failed. Disconnected; no more authentication methods available (No
further authentication methods available.).
(6779326) /Jen B. <jen@sedition.org>/-----(Ombruten)
6779327 2001-07-22 00:48 +0200 /43 rader/ Marcus Meissner <mm@ns.caldera.de>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-22 06:52 av Brevbäraren
Extern mottagare: "Stephanie Thomas" <customer.service@ssh.com>
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: okir@caldera.de
Mottagare: Bugtraq (import) <18244>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Marcus Meissner <mm@ns.caldera.de>
To: customer.service@ssh.com ("Stephanie Thomas"),
bugtraq@securityfocus.com, okir@caldera.de
Message-ID: <200107212248.f6LMmwi31696@ns.caldera.de>
In article <FNEKKFMHLBAMAHPEHBLMCEAGCAAA.customer.service@ssh.com> you wrote:
> Dear Secure Shell Community,
> A potential remote root exploit has been discovered
> in SSH Secure Shell 3.0.0, for Unix only, concerning
> accounts with password fields consisting of two or
> fewer characters. Unauthorized users could potentially
> log in to these accounts using any password, including
> an empty password. This affects SSH Secure Shell 3.0.0
> for Unix only. This is a problem with password
> authentication to the sshd2 daemon. The SSH Secure
> Shell client binaries (located by default in
> /usr/local/bin) are not affected.
> SSH Secure Shell 3.0.1 fixes this problem.
> ...
> ... Vulnerable ...
> ...
> Caldera Linux 2.4
Caldera is not shipping the commercial version of SSH in its Linux
distribtuins and so is NOT vulnerable except in cases where the
administrator installed the commercial version of SSH.
We are instead providing OpenSSH version 2.9p2 for all supported
platforms, which is not affected by above flaw.
Ciao, Marcus
--
_____ ___
/ __/____/ / Caldera (Deutschland) GmbH
/ /_/ __ / /__ Naegelsbachstr. 49c, 91052 Erlangen
/_____//_/ /____/ Dipl. Inf. Marcus Meissner, email: mm@caldera.de
==== /_____/ ====== phone: ++49 9131 7912-300, fax: ++49 9131 7192-399
Caldera OpenLinux
(6779327) /Marcus Meissner <mm@ns.caldera.de>/(Ombruten)
6785045 2001-07-22 10:03 +0200 /26 rader/ Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 17:50 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Extern kopiemottagare: customer.service@ssh.com
Mottagare: Bugtraq (import) <18248>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
Cc: customer.service@ssh.com
Message-ID: <tg3d7pfl0s.fsf@mercury.rus.uni-stuttgart.de>
"Stephanie Thomas" <customer.service@ssh.com> writes:
> A potential remote root exploit has been discovered
> in SSH Secure Shell 3.0.0, for Unix only, concerning
> accounts with password fields consisting of two or
> fewer characters.
A quick glance at the source code suggests that SSH 2.3.0 and 2.4.0
have the same problem. Is this true?
> Use the following patch in the source code:
It is not quite clear whether the license agreement permits
modification of the source code.
--
Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
(6785045) /Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>/
Kommentar i text 6785085 av Thomas Roessler <roessler@does-not-exist.org>
6785085 2001-07-23 17:42 +0200 /25 rader/ Thomas Roessler <roessler@does-not-exist.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 18:04 av Brevbäraren
Extern mottagare: Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Extern kopiemottagare: BUGTRAQ@SECURITYFOCUS.COM
Extern kopiemottagare: customer.service@ssh.com
Mottagare: Bugtraq (import) <18249>
Kommentar till text 6785045 av Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
On 2001-07-22 10:03:31 +0200, Florian Weimer wrote:
>A quick glance at the source code suggests that SSH 2.3.0 and
>2.4.0 have the same problem. Is this true?
I suppose we are talking about this section of ssh 2.4.0's
sshunixuser.c:
940
941 /* Authentication is accepted if the encrypted passwords are identical. */
942 #ifdef HAVE_HPUX_TCB_AUTH
943 return strncmp(encrypted_password, correct_passwd,
944 strlen(correct_passwd)) == 0;
945 #else /* HAVE_HPUX_TCB_AUTH */
946 return strcmp(encrypted_password, correct_passwd) == 0;
947 #endif /* HAVE_HPUX_TCB_AUTH */
If I read this correctly, it's certainly not a problem unless ssh is
compiled with HAVE_HPUX_TCB_AUTH defined. In that case, it may or
may not be a problem.
--
Thomas Roessler http://log.does-not-exist.org/
(6785085) /Thomas Roessler <roessler@does-not-exist.org>/
Bilaga (application/pgp-signature) i text 6785086
Kommentar i text 6786172 av Lucian Hudin <luci@warp.transart.ro>
Kommentar i text 6790873 av Sports <madboo@gwu.edu>
6785086 2001-07-23 17:42 +0200 /13 rader/ Thomas Roessler <roessler@does-not-exist.org>
Importerad: 2001-07-23 18:04 av Brevbäraren
Extern mottagare: Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Extern kopiemottagare: BUGTRAQ@SECURITYFOCUS.COM
Extern kopiemottagare: customer.service@ssh.com
Mottagare: Bugtraq (import) <18250>
Bilaga (text/plain) till text 6785085
Ärende: Bilaga till: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
iQEVAwUBO1xF1NImKUTOasbBAQKt/gf/cCyWpS+lsV5WE/C3sLqu2ZGzxvaYZWHr
Oz2VDvmdRt21zDq/jCUHF4n7HjZFSfJtn+o4Ow7zo/qvPMjQ81vorGmnuBwu9NHp
+NiRSdngNY/PKzN2o8y8Yd8pW0XDenUT3a1S+sdbT1vCRJFl8E67EE+Wff92yKqs
WLb3TWJzPZndoJFeaaTvSGnpBxbKji0KEUmbWQZwgGiRbaGlqRBuFldlXLmAz0iT
Wwb2O9IxYa3obfqi+yndoS5bcnR0MId7Z4PLaNxL9UkSfsL6WAaQFdCUDWx6t0zw
2ALXLP1kuqx62pA0lPcnlU+CAfqJ0fqVOFTdOzRcTUxS5RDkySZ/xg==
=UzVv
-----END PGP SIGNATURE-----
(6785086) /Thomas Roessler <roessler@does-not-exist.org>/
6786172 2001-07-23 19:08 +0300 /32 rader/ Lucian Hudin <luci@warp.transart.ro>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 21:51 av Brevbäraren
Extern mottagare: Thomas Roessler <roessler@does-not-exist.org>
Extern kopiemottagare: Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Extern kopiemottagare: BUGTRAQ@securityfocus.com
Extern kopiemottagare: customer.service@ssh.com
Mottagare: Bugtraq (import) <18269>
Kommentar till text 6785085 av Thomas Roessler <roessler@does-not-exist.org>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Lucian Hudin <luci@warp.transart.ro>
To: Thomas Roessler <roessler@does-not-exist.org>
Cc: Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>,
<BUGTRAQ@securityfocus.com>, <customer.service@ssh.com>
Message-ID: <Pine.LNX.4.30.0107231907180.30119-100000@warp.transart.ro>
>
> >A quick glance at the source code suggests that SSH 2.3.0 and
> >2.4.0 have the same problem. Is this true?
>
> I suppose we are talking about this section of ssh 2.4.0's
> sshunixuser.c:
>
> 940
> 941 /* Authentication is accepted if the encrypted passwords are identical. */
> 942 #ifdef HAVE_HPUX_TCB_AUTH
> 943 return strncmp(encrypted_password, correct_passwd,
> 944 strlen(correct_passwd)) == 0;
> 945 #else /* HAVE_HPUX_TCB_AUTH */
> 946 return strcmp(encrypted_password, correct_passwd) == 0;
> 947 #endif /* HAVE_HPUX_TCB_AUTH */
>
> If I read this correctly, it's certainly not a problem unless ssh is
> compiled with HAVE_HPUX_TCB_AUTH defined. In that case, it may or
the linux compile at least doesn't #define HAVE_HPUX_TCB_AUTH so
the sshd 2.4.0 is not vulnerable on linux.
Luci
(6786172) /Lucian Hudin <luci@warp.transart.ro>/----
Kommentar i text 6786930 av masse (passion för pumpakärnor)
6790873 2001-07-23 15:17 -0400 /54 rader/ Sports <madboo@gwu.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 21:04 av Brevbäraren
Extern mottagare: 'Thomas Roessler' <roessler@does-not-exist.org>
Extern mottagare: 'Florian Weimer' <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Extern kopiemottagare: BUGTRAQ@SECURITYFOCUS.COM
Extern kopiemottagare: customer.service@ssh.com
Externa svar till: madboo@gwu.edu
Mottagare: Bugtraq (import) <18303>
Kommentar till text 6785085 av Thomas Roessler <roessler@does-not-exist.org>
Ärende: RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Sports" <madboo@gwu.edu>
To: "'Thomas Roessler'" <roessler@does-not-exist.org>,
"'Florian Weimer'" <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Cc: <BUGTRAQ@SECURITYFOCUS.COM>, <customer.service@ssh.com>
Message-ID: <001101c113ac$1c4b8ae0$1200a8c0@com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What about 2.9?
- -----Original Message-----
From: Thomas Roessler [mailto:roessler@does-not-exist.org]
Sent: Monday, July 23, 2001 11:42 AM
To: Florian Weimer
Cc: BUGTRAQ@SECURITYFOCUS.COM; customer.service@ssh.com
Subject: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
On 2001-07-22 10:03:31 +0200, Florian Weimer wrote:
>A quick glance at the source code suggests that SSH 2.3.0 and
>2.4.0 have the same problem. Is this true?
I suppose we are talking about this section of ssh 2.4.0's
sshunixuser.c:
940
941 /* Authentication is accepted if the encrypted passwords are
identical. */
942 #ifdef HAVE_HPUX_TCB_AUTH
943 return strncmp(encrypted_password, correct_passwd,
944 strlen(correct_passwd)) == 0;
945 #else /* HAVE_HPUX_TCB_AUTH */
946 return strcmp(encrypted_password, correct_passwd) == 0;
947 #endif /* HAVE_HPUX_TCB_AUTH */
If I read this correctly, it's certainly not a problem unless ssh is
compiled with HAVE_HPUX_TCB_AUTH defined. In that case, it may or
may not be a problem.
- --
Thomas Roessler http://log.does-not-exist.org/
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBO1x4RXuovSIevPCzEQJgrACg7nG4kHVms/VV/fjKZPcT9OV0JRIAn2pG
Aqs6zdkLUaAYXceFoA3ydrLI
=8e4m
-----END PGP SIGNATURE-----
(6790873) /Sports <madboo@gwu.edu>/-----------------
Kommentar i text 6791039 av Seth Arnold <sarnold@wirex.com>
6791039 2001-07-24 12:06 -0700 /15 rader/ Seth Arnold <sarnold@wirex.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 21:59 av Brevbäraren
Extern mottagare: BUGTRAQ@securityfocus.com
Mottagare: Bugtraq (import) <18314>
Kommentar till text 6790873 av Sports <madboo@gwu.edu>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Seth Arnold <sarnold@wirex.com>
To: BUGTRAQ@securityfocus.com
Message-ID: <20010724120642.W15481@wirex.com>
On Mon, Jul 23, 2001 at 03:17:26PM -0400, Sports wrote:
> What about 2.9?
> >A quick glance at the source code suggests that SSH 2.3.0 and
> >2.4.0 have the same problem. Is this true?
You've fallen pray to the 'product problem'. 2.9 is OpenSSH. 2.3.0,
2.4.0, and 3.0 are ssh.com. This problem is in the ssh.com version,
but not in OpenSSH.
(6791039) /Seth Arnold <sarnold@wirex.com>/(Ombruten)
6785767 2001-07-21 11:11 +0200 /19 rader/ Marcin Zurakowski <marcin@interfirma.pl>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 20:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18258>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Marcin Zurakowski <marcin@interfirma.pl>
To: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0107211105260.24318-100000@inter1.interfirma.pl>
On Fri, 20 Jul 2001, Stephanie Thomas wrote:
> an empty password. This affects SSH Secure Shell 3.0.0
I guess openssh with pam support is not vulnerable??
--
Marcin Zurakowski
InterFirma Administrator
(6785767) /Marcin Zurakowski <marcin@interfirma.pl>/
Kommentar i text 6785963 av Brian Carpio <carb02@csgsystems.com>
6785963 2001-07-23 10:31 -0600 /39 rader/ Brian Carpio <carb02@csgsystems.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 21:10 av Brevbäraren
Extern mottagare: Marcin Zurakowski <marcin@interfirma.pl>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18264>
Kommentar till text 6785767 av Marcin Zurakowski <marcin@interfirma.pl>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Brian Carpio <carb02@csgsystems.com>
To: Marcin Zurakowski <marcin@interfirma.pl>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.GSO.4.10.10107231030340.15120-100000@sylvester.co.csgsystems.com>
OpenSSH is not vulnerable at all weather or not you use PAM.. this is
SSH the commercial Version.
If you didn't pay for it then you are OK!!
--------------
Brian Carpio
CSG Systems Inc.
Open Systems Unix System Admin
x3317
--------------
--- Security is a Process NOT a Product ----
On Sat, 21 Jul 2001, Marcin Zurakowski wrote:
> On Fri, 20 Jul 2001, Stephanie Thomas wrote:
>
> > an empty password. This affects SSH Secure Shell 3.0.0
>
> I guess openssh with pam support is not vulnerable??
>
> --
>
> Marcin Zurakowski
>
> InterFirma Administrator
>
>
>
(6785963) /Brian Carpio <carb02@csgsystems.com>/(Ombruten)
Kommentar i text 6787069 av Stephanie Thomas <customer.service@ssh.com>
6787069 2001-07-23 12:17 -0700 /93 rader/ Stephanie Thomas <customer.service@ssh.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 02:01 av Brevbäraren
Extern mottagare: Brian Carpio <carb02@csgsystems.com>
Extern kopiemottagare: Marcin Zurakowski <marcin@interfirma.pl>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18280>
Kommentar till text 6785963 av Brian Carpio <carb02@csgsystems.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Stephanie Thomas <customer.service@ssh.com>
To: Brian Carpio <carb02@csgsystems.com>
Cc: Marcin Zurakowski <marcin@interfirma.pl>,
bugtraq@securityfocus.com
Message-ID: <3B5C783D.B57B14D9@ssh.com>
Hi Brian, et. al.,
Actually, this statement:
> If you didn't pay for it then you are OK!!
is not true. SSH Communications Security provides
SSH Secure Shell for non-commercial / educational
use, and commercial use on the free operating systems
(Linux / BSDs), free of charge.
Those non-commercial users of SSH Secure Shell 3.0
(who didn't pay for it) are still vulnerable.
If you are using SSH Secure Shell 3.0, whether you
paid for it or not, please upgrade ASAP. Non-commercial
/ education users can locate the upgrade at:
ftp://ftp.ssh.com/pub/ssh
Best Regards,
Steph
--
*********************************
Stephanie Thomas
Technical Support Specialist
SSH Secure Shell
GIAC Certified
Unix Security Administrator
SSH Communications Security Inc.
http://www.ssh.com/support/ssh
*********************************
Brian Carpio wrote:
>
> OpenSSH is not vulnerable at all weather or not you use PAM.. this is SSH
> the commercial Version.
>
> If you didn't pay for it then you are OK!!
>
> --------------
> Brian Carpio
> CSG Systems Inc.
> Open Systems Unix System Admin
>
> x3317
> --------------
>
> --- Security is a Process NOT a Product ----
>
> On Sat, 21 Jul 2001, Marcin Zurakowski wrote:
>
> > On Fri, 20 Jul 2001, Stephanie Thomas wrote:
> >
> > > an empty password. This affects SSH Secure Shell 3.0.0
> >
> > I guess openssh with pam support is not vulnerable??
> >
> > --
> >
> > Marcin Zurakowski
> >
> > InterFirma Administrator
> >
> >
> >
--
*********************************
Please note that for support cases,
if I have not heard otherwise within five
business days, I will assume that your issue
is resolved.
Stephanie Thomas
Technical Support Specialist
SSH Secure Shell
GIAC Certified
Unix Security Administrator
SSH Communications Security Inc.
http://www.ssh.com/support/ssh
*********************************
(6787069) /Stephanie Thomas <customer.service@ssh.com>/
6786240 2001-07-21 18:26 +0200 /22 rader/ Jaime BENJUMEA <benjumea@dte.us.es>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 22:02 av Brevbäraren
Extern mottagare: Stephanie Thomas <customer.service@ssh.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18272>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Jaime BENJUMEA <benjumea@dte.us.es>
To: Stephanie Thomas <customer.service@ssh.com>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0107211822500.26082-100000@teclix.dte.us.es>
Stephanie Thomas wrote:
>
> A potential remote root exploit has been discovered
> in SSH Secure Shell 3.0.0, for Unix only, concerning
> accounts with password fields consisting of two or
> fewer characters. Unauthorized users could potentially
> log in to these accounts using any password, including
> an empty password. This affects SSH Secure Shell 3.0.0
> for Unix only. This is a problem with password
Does anybody know if previous versions (2.4) are also affected?
(6786240) /Jaime BENJUMEA <benjumea@dte.us.es>/-----
Kommentar i text 6786391 av Jonathan A. Zdziarski <jonathan.zdziarski@micromuse.com>
6786391 2001-07-23 13:12 -0400 /36 rader/ Jonathan A. Zdziarski <jonathan.zdziarski@micromuse.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 22:36 av Brevbäraren
Extern mottagare: Jaime BENJUMEA <benjumea@dte.us.es>
Extern mottagare: Stephanie Thomas <customer.service@ssh.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18276>
Kommentar till text 6786240 av Jaime BENJUMEA <benjumea@dte.us.es>
Ärende: RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Jonathan A. Zdziarski" <jonathan.zdziarski@micromuse.com>
To: "Jaime BENJUMEA" <benjumea@dte.us.es>,
"Stephanie Thomas" <customer.service@ssh.com> Cc:
<bugtraq@securityfocus.com> Message-ID:
<COEPIIFFJPONEJNLHKOEIEGDCBAA.jonathan.zdziarski@micromuse.com>
Both 2.3.0 and 2.4.0 don't appear to be vulnerable on my system (Intel
Solaris 8). 3.0.0 *was* vulnerable, however, and I was able to easily
exploit the system.
-----Original Message-----
From: Jaime BENJUMEA [mailto:benjumea@dte.us.es]
Sent: Saturday, July 21, 2001 12:27 PM
To: Stephanie Thomas
Cc: bugtraq@securityfocus.com
Subject: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
Stephanie Thomas wrote:
>
> A potential remote root exploit has been discovered
> in SSH Secure Shell 3.0.0, for Unix only, concerning
> accounts with password fields consisting of two or
> fewer characters. Unauthorized users could potentially
> log in to these accounts using any password, including
> an empty password. This affects SSH Secure Shell 3.0.0
> for Unix only. This is a problem with password
Does anybody know if previous versions (2.4) are also affected?
(6786391) /Jonathan A. Zdziarski <jonathan.zdziarski@micromuse.com>/(Ombruten)
6786276 2001-07-23 18:03 +0200 /42 rader/ Roman Drahtmueller <draht@suse.de>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-23 22:09 av Brevbäraren
Extern mottagare: Stephanie Thomas <customer.service@ssh.com>
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: security@suse.de
Mottagare: Bugtraq (import) <18273>
Kommentar till text 6775914 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Roman Drahtmueller <draht@suse.de>
To: Stephanie Thomas <customer.service@ssh.com>,
<bugtraq@securityfocus.com>, <security@suse.de>
Message-ID: <Pine.LNX.4.33.0107231751510.15489-100000@dent.suse.de>
> From: Stephanie Thomas <customer.service@ssh.com>
> To: bugtraq@securityfocus.com
> Date: Fri, 20 Jul 2001 17:34:02 -0700
> Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
[...]
> PLATFORMS IMPACTED:
>
> Red Hat Linux 6.1 thru 7.1
> Solaris 2.6 thru 2.8
> HP-UX 10.20
> HP-UX 11.00
> Caldera Linux 2.4
> Suse Linux 6.4 thru 7.0
Numerous requests force an additional statement.
The ssh versions 3.* are not shipped with SuSE Linux, all versions of
the distribution.
Thanks to Frank Denis for pointing this out on bugtraq.
Since most of the mentioned systems are older than ssh-3.*, it seems
logical that these systems can't be affected by default. It should
have been mentioned that the platforms mentioned above are vulnerable
if the said version of ssh has been installed on them. I wish for
more precision in future security announcements from ssh.com.
Roman Drahtmüller,
SuSE Security.
--
- -
| Roman Drahtmüller <draht@suse.de> // "Caution: Cape does |
SuSE GmbH - Security Phone: // not enable user to fly."
| Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) |
- -
(6786276) /Roman Drahtmueller <draht@suse.de>/(Ombruten)
Kommentar i text 6787085 av Stephanie Thomas <customer.service@ssh.com>
6787085 2001-07-23 16:04 -0700 /81 rader/ Stephanie Thomas <customer.service@ssh.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 02:09 av Brevbäraren
Extern mottagare: Roman Drahtmueller <draht@suse.de>
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: security@suse.de
Mottagare: Bugtraq (import) <18283>
Kommentar till text 6786276 av Roman Drahtmueller <draht@suse.de>
Ärende: RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Stephanie Thomas" <customer.service@ssh.com>
To: "Roman Drahtmueller" <draht@suse.de>,
<bugtraq@securityfocus.com>, <security@suse.de>
Message-ID: <FNEKKFMHLBAMAHPEHBLMMEAHCAAA.customer.service@ssh.com>
Hi Roman and Others,
Thanks for the feedback.
SSH Secure Shell 3.0.0 does not ship with any
of the operating systems mentioned, nor does the
announcement specify that it does. However, if a
user has explicitly installed SSH Secure Shell 3.0.0
on any of the listed operating systems, they are
vulnerable to this potential exploit.
Please understand that we receive many support requests
from administrators using either the commercial or
non-commercial versions of SSH Secure Shell on SuSe, Redhat,
Caldera, and other Linux versions - even though SSH Secure
Shell is not bundled these operating systems. Because
of this, we wish to ensure that those users are aware that
this issue does affect them, and what they can do to
protect themselves.
We have listed those operating systems which we know
are vulnerable _with SSH Secure Shell 3.0.0 installed_.
My apologies if this was not clear in the original
announcement.
Best Regards,
Steph
-----Original Message-----
From: Roman Drahtmueller [mailto:draht@suse.de]
Sent: Monday, July 23, 2001 9:03 AM
To: Stephanie Thomas; bugtraq@securityfocus.com; security@suse.de
Subject: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
> From: Stephanie Thomas <customer.service@ssh.com>
> To: bugtraq@securityfocus.com
> Date: Fri, 20 Jul 2001 17:34:02 -0700
> Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
[...]
> PLATFORMS IMPACTED:
>
> Red Hat Linux 6.1 thru 7.1
> Solaris 2.6 thru 2.8
> HP-UX 10.20
> HP-UX 11.00
> Caldera Linux 2.4
> Suse Linux 6.4 thru 7.0
Numerous requests force an additional statement.
The ssh versions 3.* are not shipped with SuSE Linux, all versions of
the distribution.
Thanks to Frank Denis for pointing this out on bugtraq.
Since most of the mentioned systems are older than ssh-3.*, it seems
logical that these systems can't be affected by default. It should
have been mentioned that the platforms mentioned above are vulnerable
if the said version of ssh has been installed on them. I wish for
more precision in future security announcements from ssh.com.
Roman Drahtmüller,
SuSE Security.
--
- -
| Roman Drahtmüller <draht@suse.de> // "Caution: Cape does |
SuSE GmbH - Security Phone: // not enable user to fly."
| Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) |
- -
(6787085) /Stephanie Thomas <customer.service@ssh.com>/(Ombruten)
Kommentar i text 6790996 av Emre Yildirim <emre@vsrc.uab.edu>
6790996 2001-07-23 19:11 -0500 /26 rader/ Emre Yildirim <emre@vsrc.uab.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 21:45 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: customer.service@ssh.com
Mottagare: Bugtraq (import) <18310>
Kommentar till text 6787085 av Stephanie Thomas <customer.service@ssh.com>
Ärende: RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Emre Yildirim" <emre@vsrc.uab.edu>
To: <bugtraq@securityfocus.com>
Cc: <customer.service@ssh.com>
Message-ID: <1101.138.26.156.4.995933493.squirrel@www.vsrc.uab.edu>
> SSH Secure Shell 3.0.0 does not ship with any
> of the operating systems mentioned, nor does the
> announcement specify that it does. However, if a
> user has explicitly installed SSH Secure Shell 3.0.0
> on any of the listed operating systems, they are
> vulnerable to this potential exploit.
>
I don't want to drag this boring thread any longer, but in
your advisory, it stated that OpenBSD and NetBSD were
not vulnerable. So...if I install SSH 3.0.0 on one of those
(even though the already come with openssh), ssh will not
be vulnerable to this bug? Or will it? I think that part
created a little confusion.
Cheers
(6790996) /Emre Yildirim <emre@vsrc.uab.edu>/-------
Kommentar i text 6795607 av Stephanie Thomas <customer.service@ssh.com>
6795607 2001-07-25 10:17 -0700 /47 rader/ Stephanie Thomas <customer.service@ssh.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-25 20:16 av Brevbäraren
Extern mottagare: Emre Yildirim <emre@vsrc.uab.edu>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18336>
Kommentar till text 6790996 av Emre Yildirim <emre@vsrc.uab.edu>
Ärende: RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: "Stephanie Thomas" <customer.service@ssh.com>
To: "Emre Yildirim" <emre@vsrc.uab.edu>, <bugtraq@securityfocus.com>
Message-ID: <FNEKKFMHLBAMAHPEHBLMAEAJCAAA.customer.service@ssh.com>
Hi Emre,
We have tested OpenBSD and NetBSD, and have found
that they do not experience this vulnerability,
even with ssh 3.0.0 installed.
This is most likely due to the method used to encrypt the
password in /etc/passwd or /etc/shadow.
Best Regards,
Steph
-----Original Message-----
From: Emre Yildirim [mailto:emre@vsrc.uab.edu]
Sent: Monday, July 23, 2001 5:12 PM
To: bugtraq@securityfocus.com
Cc: customer.service@ssh.com
Subject: RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
> SSH Secure Shell 3.0.0 does not ship with any
> of the operating systems mentioned, nor does the
> announcement specify that it does. However, if a
> user has explicitly installed SSH Secure Shell 3.0.0
> on any of the listed operating systems, they are
> vulnerable to this potential exploit.
>
I don't want to drag this boring thread any longer, but in
your advisory, it stated that OpenBSD and NetBSD were
not vulnerable. So...if I install SSH 3.0.0 on one of those
(even though the already come with openssh), ssh will not
be vulnerable to this bug? Or will it? I think that part
created a little confusion.
Cheers
(6795607) /Stephanie Thomas <customer.service@ssh.com>/
Kommentar i text 6795731 av Eugene Medynskiy <eugenem@brainlink.com>
6795731 2001-07-25 14:30 -0500 /64 rader/ Eugene Medynskiy <eugenem@brainlink.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-25 20:51 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18338>
Kommentar till text 6795607 av Stephanie Thomas <customer.service@ssh.com>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: Eugene Medynskiy <eugenem@brainlink.com>
To: bugtraq@securityfocus.com
Message-ID: <3B5F1E42.7080505@brainlink.com>
This only affects systems that use crypt() to validate passwords. If
you use md5 or blowfish instead (which OpenBSD, NetBSD, and Debian
Linux, among others do by default) you should not be vulnerable.
--
-- Eugene Medynskiy
"You can't fight in here, this is the War Room!"
Stephanie Thomas wrote:
> Hi Emre,
>
> We have tested OpenBSD and NetBSD, and have found
> that they do not experience this vulnerability,
> even with ssh 3.0.0 installed.
>
> This is most likely due to the method used to encrypt the
> password in /etc/passwd or /etc/shadow.
>
> Best Regards,
>
> Steph
>
> -----Original Message-----
> From: Emre Yildirim [mailto:emre@vsrc.uab.edu]
> Sent: Monday, July 23, 2001 5:12 PM
> To: bugtraq@securityfocus.com
> Cc: customer.service@ssh.com
> Subject: RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
>
>
>
>
>>SSH Secure Shell 3.0.0 does not ship with any
>>of the operating systems mentioned, nor does the
>>announcement specify that it does. However, if a
>>user has explicitly installed SSH Secure Shell 3.0.0
>>on any of the listed operating systems, they are
>>vulnerable to this potential exploit.
>>
>>
>
> I don't want to drag this boring thread any longer, but in
> your advisory, it stated that OpenBSD and NetBSD were
> not vulnerable. So...if I install SSH 3.0.0 on one of those
> (even though the already come with openssh), ssh will not
> be vulnerable to this bug? Or will it? I think that part
> created a little confusion.
>
>
> Cheers
>
>
>
>
>
(6795731) /Eugene Medynskiy <eugenem@brainlink.com>/(Ombruten)
6786792 2001-07-23 19:49 +0100 /28 rader/ Antonomasia <ant@notatla.demon.co.uk>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 00:12 av Brevbäraren
Extern mottagare: neldredge@hmc.edu
Extern kopiemottagare: aefrisch@lorentzian.com
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18279>
Ärende: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
------------------------------------------------------------
From: ant@notatla.demon.co.uk (Antonomasia)
To: neldredge@hmc.edu
Cc: aefrisch@lorentzian.com, bugtraq@securityfocus.com
Message-ID: <20010723184924.A14B046A8@notatla.demon.co.uk>
From: Nate Eldredge <neldredge@hmc.edu>
> What's wrong with just using `strcmp' (i.e. no constraint at all)? After
> all, what you want to know is just whether the two strings are identical,
> period. And unless crypt() and /etc/shadow are both broken, it will stop
> at the right place. I realize it goes against the reflexive "only strn*
> functions are safe" idea, but that shouldn't substitute for thinking...
strcmp() with one argument as a crypt() output would be OK provided
any password aging information had first been removed from the field
in the comparison.
Code to detect accounts without passwords ought to check this too as
"::" is not the only value that is open to all. "Essential System
Administration" 2nd Edition by Frisch falls down here on p344.
--
##############################################################
# Antonomasia ant notatla.demon.co.uk #
# See http://www.notatla.demon.co.uk/ #
##############################################################
(6786792) /Antonomasia <ant@notatla.demon.co.uk>/(Ombruten)