Date: Mon, 24 Feb 1997 22:52:15 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: disallow setuid root shells? Message-ID: <Mutt.19970224225215.j@uriah.heep.sax.de> In-Reply-To: <199702240549.VAA01306@lightside.com>; from Jake Hamby on Feb 23, 1997 21:49:08 -0800 References: <199702240549.VAA01306@lightside.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Jake Hamby wrote:
> access. Under Solaris, I've discovered that none of the standard shells
> will allow a user to gain root privileges through a setuid root shell!
You must have a very weird version of Solaris:
sunny% uname -sr
SunOS 5.5.1
sunny% ls -l ksh
-rwsr-xr-x 1 root other 180816 Feb 24 22:24 ksh
sunny% ./ksh
# id
uid=107(j) gid=2000(netra) euid=0(root)
# exit
Note also the handling of the -p flag in the Korn shell (and also in
our /bin/sh). It is in effect if the shell detects UID != EUID, and
resetting it causes a `setuid(getuid())'. Same in our /bin/sh.
> Comments?
Objected. It won't help very much. I've been working in the past
with systems that did it, and thinking about possible ways to defeat
this measure didn't take longer than 30 seconds. (For example, make a
copy of `vi' setuid, and use its feature to spawn a shell from there.)
> While we're on the topic, I've always wondered about Perl 5's configure
> messages about "secure setuid scripts". What exactly makes an OS capable of
> hosting "secure" Perl or shell scripts,
It does a fair amount of `taint checks' against various programmer
errors. I think setuid perl scripts are very often much more secure
than quickly hacked setuid C wrappers. Perl's taint checks aren't
something added afterwards, but they are inherent in all operations it
does, and the `tainted' flag is inherited with any variable whose
contents is derived from command-line arguments, user input, or
envioronment variables. It usually remembers this taintedness much
longer than any programmer, passing those strings innocently and
unchecked across three levels of subroutines...
A few examples:
uriah # cat > foo.pl
#!/usr/bin/suidperl
system("ls");
^D
uriah # ls -l foo.pl
-rwsr-xr-x 1 j bin - 35 Feb 24 22:34 foo.pl*
uriah # ./foo.pl
Insecure PATH at ./foo.pl line 3.
No $PATH has been set yet, thus all external commands are prohibited.
uriah # cat > foo.pl
#!/usr/bin/suidperl
$ENV{'PATH'} = "/bin:/usr/bin";
system("ls");
^D
uriah # ./foo.pl
#mutta01041# gated
...
Now it works.
uriah # cat > foo.pl
#!/usr/bin/suidperl
$ENV{'PATH'} = "/bin:/usr/bin";
open(FOO, ">$ENV{'TERM'}") || die "Cannot open $ENV{'TERM'}.\n";
^D
uriah # ./foo.pl
Insecure dependency in open at ./foo.pl line 5.
The filename about to be created would have been dependant of the
environment. Forbidden.
uriah # cat > foo.pl
#!/usr/bin/suidperl
$ENV{'PATH'} = "/bin:/usr/bin";
$mumble = $ENV{'TERM'};
system "echo $mumble";
^D
uriah # ./foo.pl
Insecure dependency in system at ./foo.pl line 6.
This system() call might contain shell metacharacters, hence it would
actually result in calling /bin/sh, with a `tainted' value.
Forbidden.
uriah # cat > foo.pl
#!/usr/bin/suidperl
$ENV{'PATH'} = "/bin:/usr/bin";
$mumble = $ENV{'TERM'};
system "echo", $mumble;
^D
uriah # ./foo.pl
xterm
Now it's allowd. The explicit splitting of the arguments to system()
causes it to not use /bin/sh at all.
There are quite more of these examples.
> and what does this have to do with
> the /dev/fd directory (that Perl searches for)?
No idea offhand. Our suidperl doesn't seem to be dependant of
/dev/fd, but other incarnations might use it. In particular, i think
if you compile perl to autodetect the suidness, and automatically
invoke suidperl (our compilation doesn't do this), it might use
/dev/fd to pass the script down to the taintcheck compiler or such.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970224225215.j>