Date: Fri, 09 Aug 1996 23:03:59 -0600 From: Warner Losh <imp@village.org> To: security@freebsd.org Subject: mhpower@mit.edu: BoS: Re: security limitation for RSAAuthentication with StrictModes Message-ID: <199608100504.XAA16408@rover.village.org>
next in thread | raw e-mail | index | archive | help
Noticed this in bos. I beleive that FreeBSD is shipped with user uucp and is home directory, /var/spool/uucppublic, is world writable. At least that's how it was on my system and I never setup uucp :-(. People might want to take a look at this. A quick chmod 0 ~uucp fixed it for me :-). Warner ------- Forwarded Message From: mhpower@mit.edu To: ssh@clinet.fi Cc: BUGTRAQ@netspace.org Date: Fri, 09 Aug 1996 18:47:40 EDT Sender: spacey@aleph.sensenet.com Subject: BoS: Re: security limitation for RSAAuthentication with StrictModes 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 ------- End of Forwarded Message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608100504.XAA16408>