[3107] in bugtraq
Re: security limitation for RSAAuthentication with StrictModes
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Fri Aug 9 19:51:28 1996
Date: Fri, 9 Aug 1996 18:47:40 EDT
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
From: mhpower@MIT.EDU
X-To: ssh@clinet.fi
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <9608010301.AA06674@yaz-pistachio.MIT.EDU>
At http://www.cs.hut.fi/ssh/ssh-archive/messages/960801-062205-21029,
there's a description of a security problem affecting sshd version
1.2.14 and some (possibly all) earlier versions that supported RSA
based authentication. One consequence of the problem is that local
users may be able to run processes with the uid of "nobody", "uucp",
or other accounts that have publicly writeable home directories.
The RSA authentication method allows logins based in part on a public
key normally stored in $HOME/.ssh/authorized_keys. sshd does not check
the ownership or permissions of this file, regardless of the setting
of StrictModes in the configuration file. In other words, unlike the
usual ownership checking done by (for example) sendmail on .forward
files and rlogind on .rhosts files, sshd will process the contents of
the file in the same way regardless of the uid of the file owner.
Systems that are known to be vulnerable may include:
Debian Linux, including version 1.1, and specifically including
versions 1.1.0-13 and 1.1.0-14 of the "base" package. Check
/etc/passwd for: nobody:*:65534:65534:nobody:/tmp:/bin/sh
SunOS versions outside of the Solaris 2.x series, including SunOS
4.1.4. Check /etc/passwd for: uucp:*:4:8::/var/spool/uucppublic:
Other systems that have /etc/passwd entries specifying a useful
shell (or no shell) and a publicly writeable home directory.
Example exploit procedure for Debian Linux (this assumes that your
home directory is the same on "linuxhost" and "otherhost"):
linuxhost% ssh-keygen
linuxhost% mkdir /tmp/.ssh
linuxhost% cp $HOME/.ssh/identity.pub /tmp/.ssh/authorized_keys
otherhost% ssh linuxhost -l nobody
Possible actions:
Read and, if appropriate, apply the patch to ssh version 1.2.14 in
http://www.cs.hut.fi/ssh/ssh-archive/messages/960801-062205-21029
Check whether your system has any accounts whose home directory
unnecessarily grants write access to other users.
If needed, create /tmp/.ssh and/or /var/spool/uucppublic/.ssh and
confirm that other users cannot remove these files.
If you decide to alter the /etc/passwd line for nobody on your
Debian Linux system, ensure that you will not be adversely
affecting processes that run as user nobody on your system, e.g.,
see http://www.cl.cam.ac.uk/users/iwj10/debian-bugs/db/2920.html
If you have a SunOS system that is not running uucp, consider
whether it may be worthwhile to remove the uucp account and/or
remove the directory /var/spool/uucppublic.
Other aspects of impact:
On Debian Linux systems, functions that normally run as user nobody
may include the entries for finger and ident in /etc/inetd.conf,
and the updatedb entry in /etc/cron.daily/find. Unauthorized users
maybe be able to interfere with these functions. There may also be
other software configured to run as user nobody, e.g., httpd.
On SunOS systems, having the uid of uucp may allow you to interfere
with uucp networking. Also, it is possible that the directory
/var/spool/uucppublic is on an NFS filesystem. In this case, a
user able to create /var/spool/uucppublic/.ssh/authorized_keys from
one host may then be able to login to other hosts that his own
account is not permitted to access, perhaps including file servers.
Matt Power
mhpower@mit.edu
