[3694] in WWW Security List Archive
Re: Hole: nobody shell
daemon@ATHENA.MIT.EDU (John Stewart)
Wed Dec 4 16:06:31 1996
To: bzdrnja@zems.fer.hr
cc: www-security@ns2.rutgers.edu
In-reply-to: Your message of "Wed, 04 Dec 1996 09:56:07 +0100."
<199612040856.JAA24876@branka.zems.fer.hr>
Date: Wed, 04 Dec 1996 10:22:01 -0800
From: John Stewart <jns@cisco.com>
Errors-To: owner-www-security@ns2.rutgers.edu
->
-> []>
-> []>on the part of users: use "xhost(1)" to limit where your Xserver
-> []>will accept connections. This has been discussed elsewhere, and
-> []>is only as good of a solution as the sophistication of the user
-> []>(or their sysadmin). Caveat User.
->
-> This will prevent user from opening Xterm, but hole with nobody still exist.
-> A user with access to your cgi-bin can write a simple script which will just
-> copy /bin/sh to /tmp and will do a setuid on it. So, you'll have /tmp/sh
-> which is setuid nobody giving him (and other users that access).
-> Any suggestions for that ?
Same as before .... audit. Listen, if a user has access to the
machine and writes a program which allows a high order port connection
and then gives a shell, well guess what, the problem was the user had
access to the machine in the first place.
Or, to partially address what you just offered up as a problem, chroot
the server, force all programmers to use proper system or fork/exec
combinations that don't start a shell, make all CGI/SSI programs run
in perl or even better C, and don't put an interactive shell in the
chrooted env.
But, as you just said, if the user has access to write to the chrooted
env, all bets are off. They could just as easily write a program
which mails the password file offsite and, if you're in an environment
where the passwords are in the password file, start a slow attack
through password guessing.
If you can't stop the users from having access, then monitor the
development of applications and audit ad naseum.
--J
