Note: While the stoplight on this page indicates the highest possible severity level (and thus the most dire consequences if this vulnerability is indeed exploited), consult the bullet next to the link to this tutorial to check your actual susceptibility to this vulnerability.
Note: All of the problems described below can be fixed by upgrading to SSH 3.1.5, SSH 3.2.2, or OpenSSH 3.4 or higher and disabling SSH1 fallback mode.
12/6/02
Whenever a remote user interactively logs into a server
using SSH, the setsid function is used to
change the resulting child process to the privileges of
the user. However, SSH also supports non-interactive
connections, in which case the setsid
function is not called, and the child process remains in
process group of the master process. This situation could
not be exploited directly to gain root privileges, but
an exploit could possibly exist if any set-userid application
on the system relies on the login name returned by the
getlogin function instead of the real or
effective userid. This vulnerability could also allow the
creation of fake log entries on some platforms.
Exploitation would only be possible by an attacker who already
has access to an account on the server.
SSH Communications Security Secure Shell versions 2.0.13 through 3.2.1 are affected by this vulnerability. Versions 3.1.5 and 3.2.2 are fixed.
CVE 2001-0144
Since the ssh insertion vulnerability (see below) is
inherent in the SSH1 protocol,
a block of code was added to ssh1 which
detects an insertion attack and denies any packets which
are part of an attack. However, this code introduced a new
vulnerability caused by an overflow condition in an integer
variable which determines the size of an array. This makes
it possible to allocate an array of size zero, which returns
a pointer into the program's own address space. An attacker
could send a long, specially crafted packet which exploits
this condition, thereby executing arbitrary code on the server.
SSH Communications Security sshd versions 1.2.24 through 1.2.31, and OpenSSH versions prior to 2.3.0 are vulnerable. Additionally SSH Communications Security versions 2.x and 3.x are also vulnerable, if SSH1 fallback is enabled, and a vulnerable version of sshd 1.x is also installed. F-Secure 1.3.x and OSSH 1.5.7 and below are also vulnerable. ssh versions prior to 1.2.24 are not vulnerable to this attack, but are vulnerable to the insertion attack (see below).
05/23/02
In environments where the AllowedAuthentications entry in the configuration
options (for SSH Communications Security SSH Secure Shell for Servers and SSH Secure Shell for Windows
Servers versions 3.0 through 3.1.1) omit the keyword "Password" as an
authentication option, some secure shell protocol version 2 clients may be
able to override the configuration to use password authentication. This may
lead to a situation in which a system administrator intends to use stronger
authentication methods (e.g., SecurID or digital certificates) and does not
enforce requirements for strong passwords, assuming that password
authentication would not take place at all.
This potential vulnerability affects SSH Communications Security SSH Secure
Shell for Servers, SSH Secure Shell for Workstations (UNIX client running
in server mode) and SSH Secure Shell for Windows Servers versions 3.0
through 3.1.1. SSH Secure Shell for Workstations Windows client and SSH
Secure Shell for Handhelds are NOT affected by this vulnerability.
This vulnerability can be removed by:
These problems can be fixed by upgrading to OpenSSH 3.4 or higher.
CVE 2001-0553
Unix systems allow an administrator to lock an account
by changing the account's encrypted password to a string such
as "*", "!!", or "NP" in
/etc/passwd, /etc/shadow, or
wherever encrypted passwords are stored. Many Unix systems come
with a number of administrative accounts locked by default.
A flaw in the password authentication process in SSH 3.0.0 could
allow a remote attacker to log into any account which is locked
in this manner using any password or no password.
SSH Communications Security sshd 3.0.0 for Unix with password authentication enabled is affected by this vulnerability if any accounts are locked using a one- or two-character string in the encrypted password field. SSH for Windows, SSH for Unix other than version 3.0.0, and SSH servers which do not use password authentication are not affected.
The fix for this problem is to upgrade to SSH 3.0.1 or higher. Alternatively, one of the following workarounds can be applied:
/*Authentication is accepted if the encrypted passwords are identical. */
add the lines:
if (strlen(correct_passwd) < 13)
return FALSE;
and recompile.
CVE 1999-0834
RSAREF2 is an implementation of the RSA algorithm, which is used
by ssh for authentication and key exchange. A buffer overflow condition
in ssh together with a buffer overflow condition in RSAREF2
could allow a remote attacker to execute arbitrary commands with the privileges of
the ssh server, which is typically root. ssh
versions 1.2.27 and earlier if compiled with the --with-rsaref
option are vulnerable. The --with-rsaref option is not the default, so
if this option was not explicitly stated when ssh was compiled, then it is
not vulnerable.
This problem can be fixed by upgrading to ssh-1.2.28. If this is not possible, then install the ssh patch and the RSAREF2 patch. See CERT Advisory 99-15 for more information on patches. The UNIX patch command can be used to apply these patches. Note: Recompiling ssh without the --with-rsaref option will fix the vulnerability, but may be a violation of the copyright restriction on RSA if used in the United States. See the COPYING file in your ssh distribution for more details.
CVE 2001-0361
ssh uses the PKCS#1_1.5 public
key encryption standard to exchange the session key between
the client and the server when a session begins. An attacker
with the ability to capture the encrypted session from the
network could recover the session key, and thus decrypt
the session, by exploiting a flaw in the PKCS#1_1.5
standard. Although this vulnerability is inherent in the SSH1
protocol, it is infeasible in many situations due to the
large number of connections to the server that would be required
during the one-hour life span of the session key.
This attack is not feasible against OpenSSH due to limits on the number of connections to the server. Nor is it feasible against ssh-2.x running in SSH1 compatibility mode. The patch given in the CORE-SDI advisory should be applied to ssh-1.x up through ssh-1.2.31.
ssh uses a 32-bit cyclic redundancy check (CRC-32) algorithm to verify that a packet contains legitimate data. If certain cipher modes are used, a remote attacker could create an ssh packet that will decrypt to arbitrary plaintext, and a weakness in the CRC-32 algorithm could allow the attacker to forge a valid checksum so that the packet will appear to be legitimate. By inserting such packets into an existing session, the attacker could execute arbitrary commands on the system. ssh versions 1.2.23 and earlier have this vulnerability, as do F-Secure versions 1.3.4 and earlier. If you are not sure which version you are running, type ssh -V on the system, and it will tell you which version is installed.
The solution to this problem is to upgrade ssh to version 1.2.25 or higher, or to F-Secure version 1.3.5 or higher. F-Secure users with a support contract can obtain an upgrade from their local retailer.
CVE 1999-0013
CVE 1999-0248
The ssh package includes a program called the ssh-agent.
The ssh-agent manages the RSA keys for the ssh
program, and is used primarily to help users avoid having to type in their
pass phrase every time they wish to use ssh, slogin
or scp. When invoked, the ssh-agent program
creates a mode 700 directory in the /tmp directory, and then creates
an AF_UNIX socket in that directory. Later, the user will run a
program named ssh-add, which adds his or her private key
to the set of keys managed by the ssh-agent program. When
a user wishes to utilize a program which requires RSA key authentication,
the ssh client connects to the AF_UNIX socket and
asks the ssh-agent program for the appropriate key.
The vulnerability lies in the fact that when the ssh client connects to the AF_UNIX socket, it is running as super-user, or root, and performs insufficient permissions checking. This makes it possible for users to trick their ssh clients into using credentials belonging to other users. In other words, any users who utilize RSA authentication and use the ssh-agent program may have their credentials improperly used by a malicious user, who then may improperly access services or programs on a host machine.
This vulnerability affects the UNIX versions of ssh only. Specifically, ssh for UNIX versions 1.2.17 through 1.2.21 are vulnerable if installed with default permissions. Versions of ssh prior to 1.2.17 are subject to a different (but very similar) attack. Additionally, the F-Secure ssh programs, prior to version 1.3.3, are vulnerable to this attack. Version 1.1 of the Windows-based ssh client, sold by F-Secure Corporation, and versions 1.0/1.0a of the Macintosh ssh client are not vulnerable to this attack. If you are unsure of which version or brand of ssh you are running, type "ssh -V" at the command prompt and that information will be given to you by the system. If you are not sure if your version or brand of ssh is vulnerable to this type of attack, please contact the appropriate vendor.
For those using the non-commercial versions of ssh for UNIX, this vulnerability may be easily fixed. Simply upgrade to SSH version 1.2.26 or later. For those using the F-Secure ssh program, version 1.3.3 fixes this security problem. For those using the F-Secure ssh package, and who have a support contract, the fix for this vulnerability is to upgrade to version 1.3.3, which may be obtained from a local retailer.
If the above fixes are not practical, or if administrators wish to use a temporary fix until the above resolutions may be implemented, a workaround to this problem is available. The temporary workaround is for administrators to remove the setuid bit from the ssh binary. This will prevent the attack from working, but will also disable a form of authentication documented as rhosts-RSA. For example, if the ssh binary is in the /usr/local/bin directory, the following command will remove the setuid bit from the ssh binary: "chmod u-s /usr/local/bin/ssh".
CVE 2000-0575
SSH prior to 1.2.28 stores Kerberos tickets in the current
directory with the filename specified by the
KERB5CCNAME environment variable, which is
set to "none" upon login. The failure to control the
location in which the ticket is stored opens
the potential for disclosure,
either by sniffing over the network if NFS
is in use, or by other insecure protocols. If the ticket
is compromised, an attacker could impersonate the user.
SSH prior to 1.2.28 is affected by this vulnerability if
compiled with Kerberos support.
The non-interactive login vulnerability in SSH was reported in CERT Vulnerability Note 740619.
The password authentication vulnerability in SSH 3.0.0 was reported in CIAC Bulletin L-121.
Information about the buffer overflows in ssh and RSAREF2 can be found in CERT Advisory 99-15.
The ssh insertion attack was reported in a CORE SDI Advisory. The vulnerability in the insertion attack detection procedure was reported in another CORE SDI Advisory. The session key recovery vulnerability was reported in yet another CORE-SDI Advisory.
The ssh-agent vulnerability is outlined in CERT Advisory 98.03.
The SSH Secure Shell server AllowedAuthentications vulnerability was reported in CIAC Bulletin M-081.
The Kerberos ticket disclosure vulnerability was posted to Bugtraq.
For more information about SSH Communications Security's versions of ssh, be sure to visit their SSH Web site. If you are using F-Secure and need more information, please visit F-Secure Corporation.