COMMAND
sshd
SYSTEMS AFFECTED
Linux RPM ssh-1.2.27-8i.src.rpm
PROBLEM
Following is based on Sword & Shield Enterprise Security Advisory.
A vulnerable secure shell distribution is available from the
popular Zedz Consultants FTP site (formally known as replay.com).
The RedHat Linux RPM ssh-1.2.27-8i.src.rpm contains a PAM patch
which contains faulty logic allowing users to essentially pass
through the username/password authentication step and gain shell
access. It should be stressed that the ssh distribution
1.2.27-7us.rpm and 1.2.27-7i.rpm available from the web site do
not contain this vulnerability. The vulnerable distribution
(1.2.27-8i.src.rpm) is located in the "incoming" directory at
ftp://ftp.zedz.net/pub/ cryptoI/incoming (formerly
pub/crypto/incoming). It is also possible that the distribution
could have been obtained from the pub/crypto/redhat/unsorted
directory.
Due to the obscure location of the vulnerable distribution
it is not known at this time how wide spread the impact of
this vulnerability is. The vulnerable distribution has been
removed from the site and should no longer be accessible.
The vulnerable ssh distribution is patched with defective logic
related to PAM authentication. The offending code from the patch
file ssh-1.2.27-pam.patch is:
+#ifdef HAVE_PAM
+ {
+ retval = origretval;
+ pampasswd = xstrdup(password);
+ if (retval == PAM_SUCCESS)
+ retval = pam_authenticate ((pam_handle_t *)pamh, 0);
+ if (retval == PAM_SUCCESS || retval == PAM_AUTH_ERR)
+ retval = pam_acct_mgmt ((pam_handle_t *)pamh, 0);
+ xfree(pampasswd);
+ }
+#else /* HAVE_PAM */
Note the last 'if' statement - in essence whether the
pam_authenticate() call is successful or not, the pam_acct_mgmt()
call is made overwriting the contents of retval. Assuming the
pam_acct_mgmt() call is successful, and it tends to be, then the
remaining patch code dealing with PAM authentication opens a
session with:
+#ifdef HAVE_PAM
+ {
+ if (retval == PAM_SUCCESS)
+ retval = pam_open_session ((pam_handle_t *)pamh, 0);
+ return (retval == PAM_SUCCESS);
+ }
+#endif /* HAVE_PAM */
By running the patch command
patch -p0 -b < ssh-1.2.27-pam.patch
we get
patching file `ssh-1.2.27/acconfig.h'
patching file `ssh-1.2.27/auth-passwd.c'
patching file `ssh-1.2.27/config.h.in'
patching file `ssh-1.2.27/configure.in'
patching file `ssh-1.2.27/sshd.c'
The faulty PAM authentication logic is then inserted into the
auth_password() function in the auth-passwd.c file at lines
745-755 and 879-885.
The impact of this bug can be quite severe. On systems where the
/etc/ssh/sshd_config file contains 'PermitRootLogin=yes' the
effect is that any remote or local user can obtain root access by
specifying a root login and entering a non-null password.
Example, if a system (pigpen) configured with the vulnerable ssh
server package has a valid user account (joe) then the command:
% ssh -l joe pigpen
joe@pigpen's password: 123 <--- sshd prompts for password, enter '123'.
... <--- faulty authentication check performed
[joe@pigpen]$ <--- user shell accessed
Checking the syslogs also reveals signs of the problem:
1- May 8 13:12:50 pigpen sshd[13422]: connect from 10.10.10.10
2- May 8 13:12:50 pigpen sshd[13422]: log: Connection from 10.10.10.10 port 1209
3- May 8 13:12:52 pigpen PAM_pwdb[13422]: authentication failure; (uid=0) -> joe for ssh service
4- May 8 13:12:53 pigpen PAM_pwdb[13422]: (ssh) session opened for user joe by (uid=0)
5- May 8 13:12:53 pigpen sshd[13422]: log: Password authentication for joe accepted.
Note the authentication failure recorded by PAM on line 3, but
lines 4-5 show the session being opened. It is important to note
a few things here:
1) Even if an account is password locked, if it contains a
valid shell the account can be accessed.
2) Site specific user accounts are not necessary for searching
out vulnerable systems when standard Linux
distribution/package accounts like 'gdm', 'postgres', or
'mysql' will do.
This vulnerable SSH RPM has been available since March 1, 2000.
The bug discovery, test, demonstration, vendor coordination,
and advisory generation are the results of SSES, Inc. security
engineers John McNeely and Dennis Edmonds.
SOLUTION
If your ssh installation is vulnerable, you should remove the
vulnerable version and install version 1.2.27-7us. Another
alternative to consider is switching over to openssh available
from http://www.openssh.com.