Bugtraq mailing list archives
Re: security limitation for RSAAuthentication with StrictModes
From: mhpower () MIT EDU (mhpower () MIT EDU)
Date: Fri, 9 Aug 1996 18:47:40 EDT
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
Current thread:
- Re: security limitation for RSAAuthentication with StrictModes mhpower () MIT EDU (Aug 09)
- <Possible follow-ups>
- Re: security limitation for RSAAuthentication with StrictModes Alan Cox (Aug 12)