From: mikel@demax.uucp (Mikel Lechner)
Newsgroups: alt.security
Subject: Re: Setuid shell scripts, Whats the problem?
Message-ID: <1992Feb6.162413.6508@demax.uucp>
Date: 6 Feb 92 16:24:13 GMT
References: <1992Feb2.114728.27168@matilda.vut.edu.au> <1992Feb3.003936.9693@rz.uni-karlsruhe.de> <1992Feb03.191612.198991@cs.cmu.edu> <1992Feb4.170623.5192@aber.ac.uk>
Organization: Demax Software Inc.

In <1992Feb4.170623.5192@aber.ac.uk> aem@aber.ac.uk (Alec David Muffett) writes:

>Actually guys, there is a simpler way to hack most setuid shell scripts...

>when the kernel is told to exec a shell script names [sic] "fred"
>which contains the line "#!/bin/sh"
>it builds the line "/bin/sh fred" 
>goes setuid
>and execs that...

>If you make a symlink to fred called "-i"
>and execute "-i"
>the kernel builds the line "/bin/sh -i"
>goes setuid
>and execs that...

This hole is plugged in SunOS (at least >= 4.0 & perhaps some other Unixes)
in the C-shell by requiring that the flag "-b" appear in the "#!" line
(ie. "#! /bin/csh -b").  If this flag is not present the C-shell refuses
to execute SUID.  It does this check before it processes any flags.
If you use the symlink spoof the resulting command line is "/bin/csh -b -i".

The "-b" flag has the additional effect that it causes all arguments which
follow it to be passed to the shell script instead of being processed by
the C-shell.  So, at least in this case, the symlink spoof is plugged.

However, you can still take advantage of the race condition between the
exec() call and the open() of the script by the shell to trick it into
running your own script as SUID the original script's owner.  I once wrote
a program to test this.  It worked.  Then I removed all my SUID shell scripts.


--
Mikel Lechner				E-mail:		decwrl!demax!mikel
Demax Software, Inc.			Phone:		(415) 341-9017