11/14/2005 - Exploitation code for this issue is publicly available.
|Exploit publicly available||Yes|
Versions of VERITAS Cluster Server for UNIX are susceptible to a buffer overflow vulnerability that could allow a local user to create a disruption of backup/storage capabilities or potentially gain elevated privileges on a targeted server.
|VERITAS Cluster Server for UNIX||4.0||All||Solaris, AIX, Linux||VCS 4.0MP2+|
| ||3.5||All||Solaris||VCS 3.5P5+|
| ||3.5||All||HP-UX||VCS 3.5Update3+|
| ||3.5||All||AIX||VCS 3.5P1+|
| ||2.2||All||Linux||VCS 2.2MP2+|
Not Affected Product(s)
|VERITAS Cluster Server for UNIX||4.1||All||All|
|VERITAS Cluster Server for Windows||All|| || |
Symantec was notified of a buffer overflow vulnerability in VERITAS Cluster Server for UNIX part of VERITAS Storage Foundation High Availability 4.0. Proper bounds checking is not done on calls to multiple 'ha' commands associated with the VCSI18N_LANG environmental variable. The affected code is configured to run with System Administrator rights (Root SUID). Exploitation by a malicious local user could result in a disruption of backup/storage capabilities or, if successfully exploited, result in an unprivileged user gaining privileged access on the targeted server.
Symantec Engineers have verified this issue and made security updates available for the affected versions of VERITAS Cluster Server for UNIX. Symantec strongly recommends all customers immediately apply the latest updates for their supported product versions to protect against these types of threats.
The patches listed in the Affect Product table above are available from support at:
Symantec knows of no adverse customer impact from this issue.
Identifying vulnerable applications
The following commands can help you quickly and accurately identify whether you are running a vulnerable version that requires updating.
# pkginfo -l VRTSvcs | grep VERSION
- Solaris systems, run the following command:
The base version will appear to the right of the VERSION tag. If it is 3.5, or 4.0, you are vulnerable. If nothing is returned, you do not have VERITAS Cluster Server for UNIX installed.
# rpm -q -i VRTSvcs | grep Version
- Linux systems, run the following command:
Version: 2.2.rhel30 Vendor: VERITAS Software Corp.
The version (along with the platform, in this case, RHEL 3.0), will appear to the right of the Version tag. If it reads 2.2, you are vulnerable. If nothing is returned, you do not have VERITAS Cluster Server for UNIX installed.
# lslpp -l | grep VRTSvcs.rte
- AIX systems, type the following command:
VRTSvcs.rte 188.8.131.52 COMMITTED VERITAS Cluster Server 4.0
The version will appear at the end of the line (in this case, 4.0). If it includes 3.5 or 4.0, you are vulnerable. If nothing is returned, you do not have VERITAS Cluster Server for UNIX installed.
# swlist | grep VRTSvcs
- HP-UX systems, type the following command:
VRTSvcs 3.5 Veritas Cluster Server
The results may include several lines of output. Identify the line that starts with VRTSvcs and note the version number in the second column. If it reads 3.5, you are vulnerable. If this line does not appear in the output, you do not have VERITAS Cluster Server for UNIX installed.
For customers unable to apply the recommended fixes immediately, removing root suid permission on VCS 'ha' binaries and restricting access to Authorized VCS users can protect a VCS cluster from possible elevation of privileges until such time as proper updates can be applied.
NOTE: This workaround will require non-root users who require access to be assigned a valid VCS Username and password for use every time they communicate with the VCS Cluster.
NOTE: By removing the root suid permissions, a non-root user cannot communicate with VCS using root Unix Domain Sockets (UDS). By setting the VCS_TEST_HOST environment variable, the 'ha' command (e.g. hagrp) can be used by a non-root user after specifying a valid VCS username and password.
- Remove root suid permissions on any VCS 'ha' binaries
- Find affected binaries as follows: -
- On Linux, use the command "find /opt/VRTSvcs -perm 4000"
- On Solaris, AIX, HP-UX use the command "find /opt/VRTSvcs -perm 4755"
- chmod u-s
- Restrict access to Cluster Nodes to only Authorized VCS users
- Check the value of Cluster attribute AllowNativeCliUsers as: -
- haclus -value AllowNativeCliUsers
- If the value of the above attribute is 1, perform the following steps: -
- haconf -makerw
- haclus -modify AllowNativeCliUsers 0
- haconf -dump -makero
Force non-root users to specify a valid VCS Username and password and use TCP for communication by setting the following environment variable:
- VCS_TEST_HOST= where value is the hostname of the cluster node.
e.g., export VCS_TEST_HOST=sysa where sysa is the hostname of the cluster node.
WARNING: Any 'cron' jobs running as a non-root user and using a VCS 'ha' command may fail because of not specifying a valid VCS username and password. For such cases, the appropriate VCS patch listed above should be applied.
As part of normal best practices, Symantec strongly recommends:
- Restricting access to administration or management systems to privileged users.
- Restricting remote access, if required, to trusted/authorized systems only.
- Running under the principle of least privilege where possible to limit the impact of exploit by threats such as this.
- Keeping all operating systems and applications updated with the latest vendor patches.
- Following a multi-layered approach to security. Run both firewall and antivirus applications, at a minimum, to provide multiple points of detection and protection to both inbound and outbound threats.
- Deploying network intrusion detection systems to monitor network traffic for signs of anomalous or suspicious activity. This may aid in detection of attacks or malicious activity related to exploitation of latent vulnerabilities
A CVE candidate number will be requested from The Common Vulnerabilities and Exposures (CVE) initiative. This advisory will be revised as required once the CVE candidate number has been assigned. This issue is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems.
Symantec would like to thank Kevin Finisterre, for reporting this issue and for providing coordination while Symantec resolved it.
Symantec takes the security and proper functionality of our products very seriously. As founding members of the Organization for Internet Safety (OISafety), Symantec supports and follows the principles of responsible disclosure. Symantec also subscribes to the vulnerability disclosure guidelines outlined by the National Infrastructure Advisory Council (NIAC).
Please contact firstname.lastname@example.org if you feel you have discovered a security issue in a Symantec product. A Symantec Product Security team member will contact you regarding your submission. Symantec strongly recommends using encrypted email for reporting vulnerability information to email@example.com. The Symantec Product Security PGP key can be found at the end of this message.
Symantec has developed a Product Vulnerability Response document outlining the process we follow in addressing suspected vulnerabilities in our products. This document is available below.
Copyright (c) 2009 by Symantec Corp.
Permission to redistribute this alert electronically is granted as long as it is not edited in any way unless authorized by Symantec Security Response. Reprinting the whole or part of this alert in any medium other than electronically requires permission from firstname.lastname@example.org.
The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.
Symantec, Symantec products, Symantec Security Response, and email@example.com are registered trademarks of Symantec Corp. and/or affiliated companies in the United States and other countries. All other registered and unregistered trademarks represented in this document are the sole property of their respective companies/owners.
Initial Post on: Tuesday, 08-Nov-05 12:20:00
Last modified on: Tuesday, 06-Dec-05 21:04:25