Reply With QuoteSounds like we can expect a flood of upgrades to OpenSSH from the major Linux distro's over the next few days.
Jim H
On June 21 OpenSSH 3.3 was released. The key emphasis for this release was the compatability of privelage separation on linux and solaris operation systems. This feature allows a small portion of the program to be run as root, and the remainder to be forked to a chroot-jail. Having these settings in effect minimize the chances of exploitation of a system.
Recently Theo De Raadt posted to numerous mailing lists explaining that the OpenSSH team, in collaboration with ISS, will be releasing information on a security bug in OpenSSH. This bug is not fixed by the latest release of OpenSSH and can only be avoided by implementing privelage separation.
It is important that you upgrade OpenSSH as soon as possible. Fortunately Privelage separation is enabled by default. To verify check for the following in /usr/local/etc/sshd_config
#UsePrivelageSeparation yes
Although the option is commented it is still in effect by default. Default configuration settings are commented in OpenSSH configuration files.
If you've upgraded your OpenSSH to version 3.3 and you don't see UsePrivelageSepration, it is due to an sshd_config file already being present prior to updating. To remedy this problem, back up or remove your old sshd_config and make install again.
This security bug will most assuredly affect you, so it is important that you upgrade your system accordingly.
Sounds like we can expect a flood of upgrades to OpenSSH from the major Linux distro's over the next few days.
Jim H
What exactly is OpenSSH and what do I need to do...I have Suse 8.0
Thanks.
OpenSSH is a secure shell program. It's like telnet or rlogin, but all sessions are encrypted. It can also be used for ftp like services with sftp.
Chances are Suse 8.0 comes with OpenSSH by default. You can check using the command:
$ whereis ssh
To check the version:
$ ssh -v
To see if it's running:
$ netstat -a | grep 22
$ ps -aux | grep sshd
If it is running and you want to shut it down:
$ killall sshd
If you don't use ssh to remotely login into your computer, I would recommend shutting it down and disabling it on startup. This can be accomplished by either modifying your xinetd files or your rc files. I'm not sure where it is controlled in Suse 8.0.
This was posted on the Red Hat mailing lists in response to an inquiry as to when Red Hat would be releasing an update.
Just a note on this, please note that to this point, all that has been released is an assurance that the exploit doesn't affect openssh when using PrivSep . . . no one has produced the exploit . . . no one has shown proof that a PrivSep setup isn't vunerable.
So, not saying that this is or isn't the case, just wanted to make people aware that there's no proof that what has been published about PrivSep is really true. To that note, we will have fixed packages out as soon as we are sure that our packages are fixed :-) Oddly enough, this is the way that Red Hat always releasing updates.
- jkt
--
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
Jay Turner, QA Manager Red Hat, Inc.
So I guess they have yet to verify this bug report.
Jim H
It's probably good that they aren't jumping the gun. Although, somehow I doubt one of the head develepors of the program would be spreading false rumours. Theo may be considered an ass by some, but I don't think he is that bad!
More info on this.
ISS X-Force recommends that system administrators disable unused OpenSSH authentication mechanisms. Administrators can remove this vulnerability by disabling the Challenge-Response authentication parameter within the OpenSSH daemon configuration file. This filename and path is typically: /etc/ssh/sshd_config. To disable this parameter, locate the corresponding line and change it to the line below:
ChallengeResponseAuthentication no
The "sshd" process must be restarted for this change to take effect. This workaround will permanently remove the vulnerability. X-Force recommends that administrators upgrade to OpenSSH version 3.4 immediately. This version implements privilege separation, contains a patch to block this vulnerability, and contains many additional pro-active security fixes. Privilege separation was designed to limit
exposure to known and unknown vulnerabilities. Visit
http://www.openssh.com for more information.
-----
Red Hat has not yet announced whether or not this exploit is present in their OpenSSH release. However, ChallengeResponseAuthentication defaults to yes on my 7.3 box.
But this was posted by another Red Hat user.
Reviewing the announcement, I wonder if this affects Red Hat's OpenSSH
at all... The output of the configure process indicates positively that
the affected BSD Auth and S/KEY authentication mechanisms are not
available
<snippage.....>
RHL OpenSSH build:
OpenSSH has been configured with the following options:
User binaries: /usr/bin
System binaries: /usr/sbin
Configuration files: /etc/ssh
Askpass program: /usr/libexec/openssh/ssh-askpass
Manual pages: /usr/share/man/manX
PID file: /var/run
sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin
Manpage format: doc
PAM support: yes
KerberosIV support: no
Smartcard support: no
AFS support: no
S/KEY support: no
TCP Wrappers support: yes
MD5 password support: no
IP address in $DISPLAY hack: no
Use IPv4 by default hack: no
Translate v4 in v6 hack: yes
BSD Auth support: no
Random number source: OpenSSL internal ONLY
Jim H
OK, from reading this advisory and the options Red Hat uses to compile OpenSSH it looks to me like Red Hat IS NOT vulnerable.
OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options must be enabled
before the OpenSSH binaries are compiled for the vulnerable condition to
be present.
As mentioned in my previous post these options are not enabled at compile time by Red Hat.
http://online.securityfocus.com/arch...3/2002-06-29/0
Jim H
When I ./configure OpenSSH 3.3 on my box (slackware) it says that S/key and BSD Auth support are not enabled. Although the values are still set to yes in the default sshd_config. I think the problem is more prominent on OpenBSD and FreeBSD releases, as the advisories say.
It's obviously still best to upgrade to 3.4 as it fixes other bugs as well.
Appendix A. - Vendor Information (coutesy of CERT - the bastids :P)
This appendix contains information provided by vendors for this
advisory. As vendors report new information to the CERT/CC, we will
update this section and note the changes in our revision history. If a
particular vendor is not listed below, we have not received their
comments.
Compaq Computer Corporation
SOURCE: Compaq Computer Corporation, a wholly-owned subsidiary of Hewlett-Packard Company and Hewlett-Packard Company HP Services.
Software Security Response Team
x-ref:SSRT2263
At the time of writing this document, Compaq is currently
investigating the potential impact to HP Tru64 UNIX, commercial
version of SSH for V5.1a.
As further information becomes available notice will be provided of
the completion/availability of any necessary patches through standard
product and security bulletin announcements and be available from your
normal HP Services support channel.
Caldera
Caldera OpenLinux OpenSSH has neither the S/KEY nor BSD Auth features
compiled in, so it is not vulnerable to the Challenge/Response
vulnerability. We do have the ChallengeResponseAuthentication option
on by default, however, so to be safe, we recommend that the option be
disabled in the sshd_config file.
In addition, the sshd_config PAMAuthenticationViaKbdInt option is off
by default, so OpenLinux is not vulnerable to the other alleged
vulnerability in a default configuration, either. However, Caldera
recommends that this option be disabled if it has been enabled by the
system administrator.
Cray, Inc.
Cray, Inc. has found the OpenSSH released in Cray Open Software 3.0 to
be vulnerable. Please see Field Notice 5105 and spr 722588 for fix
information.
Debian
Debian 2.2 (the current stable release) is not affected by these
problems. The current versions of our "testing" distribution, to
become Debian 3.0, and our "unstable" distribution, are both affected
by default.
We recommend that users be certain that both:
ChallengeResponseAuthentication no
and
PAMAuthenticationViaKbdInt no
are present and uncommented in /etc/ssh/sshd_config (and that the
server is restarted). Also, we recommend the use of version 3.3p1, now
available from security.debian.org (DSA-134). Stable users do not need
to upgrade and may wish to wait until the packages have received
better testing.
We intend to provide 3.4p1 packages in the near future.
Engarde
Guardian Digital ships OpenSSH in all versions of EnGarde Secure
Linux. Version 3.3p1 was introduced by ESA-20020625-015 on June 25,
2002. This update introduces privilege separation. All users are
strongly urged to upgrade to this version as soon as possible.
An upgrade to version 3.4p1 (which properly fixes the bugs) will be
made available sometime in the next few days.
Hewlett-Packard Company
Hewlett-Packard provides a version of SSH: HP-UX Secure Shell
(T1471AA) for HP-UX versions 11.00 and 11i. We are investigating to
determine whether this product is vulnerable.
IBM Corporation
IBM's AIX operating system does not ship with OpenSSH; however,
OpenSSH is available for installation on AIX via the Linux Affinity
Toolkit. The version included on the CD containing the Toolkit is
vulnerable to the latest discovered vulnerability discussed here as is
the version of OpenSSH available for downloading from the IBM Linux
Affinity website. Anyone running this version is advised to follow the
recommendations above to limit their vulnerability.
We working with the changes for version 3.4 and will have a new
package availble for download as soon as possible. When available the
new packages can be downloaded from:
http://www6.software.ibm.com/dl/aixtbx/aixtbx-p
This site contains Linux Affinity applications containing
cryptographic algorithms, and new users of this site are asked to
register first.
Lotus
Lotus products are not vulnerable to this problem.
Mandrake Software
MandrakeSoft released OpenSSH 3.3p1 in updates Monday night to
mitigate this vulnerability. Updates to OpenSSH 3.4p1 will be
available for download later this week.
Microsoft Corporation
Microsoft products are not affected by the issues detailed in this
advisory.
Network Appliance
NetApp systems are not vulnerable to this problem.
OpenBSD
See http://www.openbsd.org/errata.html#sshd
OpenSSH
See http://www.openssh.com/txt/preauth.adv
Process Software
MultiNet, TCPware, and SSH for OpenVMS are not affected by the
problems outlined in this advisory.
RedHat Inc.
Red Hat Linux versions 7, 7.1, 7.2 and 7.3 as well as Red Hat Linux
Advanced Server version 2.1 ship with OpenSSH. The Red Hat Linux
OpenSSH packages were not compiled with either BSD_AUTH or SKEY
enabled, therefore in order to be vulnerable to this issue a user
would need to have enabled the configuration option
"PAMAuthenticationViaKbdInt" in their sshd configuration file (the
default is disabled).
We are continuing to investigate this vulnerability and will release
updated packages where appropriate.
SGI
At this time, SGI does not ship OpenSSH as a part of IRIX.
The OpenSSH privilege separation code mostly works with IRIX, but it
uses a flag to mmap that isn't in IRIX (MAP_ANON) for compression so
you can't have both on at the same time. IRIX doesn't ship with PAM so
a lot of the PAM issues aren't issues for us.
Posting Permissions
Bookmarks