From owner-freebsd-hackers Mon Feb 24 15:25:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA28143 for hackers-outgoing; Mon, 24 Feb 1997 15:25:26 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA28132 for ; Mon, 24 Feb 1997 15:25:23 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA05953 for hackers@FreeBSD.ORG; Tue, 25 Feb 1997 00:25:01 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA01421; Mon, 24 Feb 1997 22:52:15 +0100 (MET) Message-ID: 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? References: <199702240549.VAA01306@lightside.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702240549.VAA01306@lightside.com>; from Jake Hamby on Feb 23, 1997 21:49:08 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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. ;-)