Revision History

11/14/2005 - Exploitation code for this issue is publicly available.

Severity

Medium

Remote Access                  No
Local Access                     Yes
Authentication Required      Yes
Exploit Publicly Available     Yes

Overview

Versions of VERITAS Cluster Server are susceptible to a buffer overflow vulnerability that could allow a local user to create a denial of service situation or potentially gain elevated privileges on a targeted server.

Affected Products

-VERITAS Storage Foundation Cluster File System HA  4.0 for AIX, Linux and Solaris

-VERITAS SANPoint Control Quickstart 3.5 for Solaris

-VERITAS Storage Foundation For DB2 HA 1.0 for AIX, 4.0 for AIX and Solaris

-VERITAS Storage Foundation for Oracle HA 3.0 for AIX, 3.5 for Solaris, 4.0 for Solaris and AIX

-VERITAS Storage Foundation for Oracle Real Application Clusters 3.5 for Solaris, 4.0 for AIX, Linux and Solaris

-VERITAS Storage Foundation for Sybase HA 4.0 for Solaris

-VERITAS Storage Foundation HA for UNIX 2.2 for Linux and VMWare ESX, 3.4 for AIX, 3.5 for HP-UX and Solaris, 4.0 for AIX, Linux and Solaris

-VERITAS Cluster Server 2.2 for Linux (all versions),  3.5 for Solaris, HP-UX, AIX (all versions),  4.0 for Solaris, AIX, Linux (all versions)

VERITAS Cluster Server 4.1 on all platforms

VERITAS Cluster Server for Windows

Details

Symantec was notified of a buffer overflow vulnerability in VERITAS Cluster Server,  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 Response

Symantec Engineers have verified this issue and made security updates available for the affected versions of VERITAS Cluster Server. 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 above are available from Support at:

VERITAS Cluster Server - Security Fix for VCS 3.5 (all versions) on Solaris -  http://support.veritas.com/docs/279917

VERITAS Cluster Server - Security Fix for VCS 4.0 (all versions) on Solaris -  http://support.veritas.com/docs/279918

VERITAS Cluster Server - Security Fix for VCS 3.5 (all versions) on AIX -  http://support.veritas.com/docs/279945

VERITAS Cluster Server - Security Fix for VCS 4.0 (all versions) on AIX -  http://support.veritas.com/docs/279946

VERITAS Cluster Server - Security Fix for VCS 3.5 (all versions) for HP-UX -  http://support.veritas.com/docs/279947

VERITAS Cluster Server - Security Fix for VCS 2.2 (all versions) on Red Hat Advanced Server 2.1 -  http://support.veritas.com/docs/279948

VERITAS Cluster Server - Security Fix for VCS 2.2 (all versions) on Red Hat Enterprise Linux 3.0 (i686) -  http://support.veritas.com/docs/279950

VERITAS Cluster Server - Security Fix for VCS 2.2 (all versions) on Red Hat Enterprise Linux 3.0 (ia64) -  http://support.veritas.com/docs/279951

VERITAS Cluster Server - Security Fix for VCS 4.0 (all versions) on Red Hat Enterprise Linux 3.0 (i686) -  http://support.veritas.com/docs/279952

VERITAS Cluster Server - Security Fix for VCS 2.2 (all versions) on VMWare ESX -  http://support.veritas.com/docs/279953

VERITAS Cluster Server - Security Fix for VCS 2.2 (all versions) on SuSE Linux Enterprise Server 8 SP3 -  http://support.veritas.com/docs/279954

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.

On Solaris systems, run the following command:

# pkginfo -l VRTSvcs | grep VERSION
  VERSION:  3.5

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 installed.

On Linux systems, run the following command:

# rpm -q -i VRTSvcs | grep Version
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 installed.

On AIX systems, type the following command:

# lslpp -l | grep VRTSvcs.rte
 VRTSvcs.rte           4.0.0.0  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 installed.

On HP-UX systems, type the following command:

# swlist | grep VRTSvcs
 ...
 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 installed.



Mitigation/Workarounds

For customers who are unable to apply the recommended fixes immediately, removing root suid permission on VERITAS Cluster Server 'ha' binaries and restricting access to Authorized Cluster Server users can protect a 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 VERITAS Cluster Server username and password for use every time they communicate with the VCS cluster.

1. Remove root suid permissions on any Cluster Server 'ha' binaries

a. Find affected binaries as follows:

i. On Linux, use the command "find /opt/VRTSvcs -perm 4000"

ii. On Solaris, AIX, HP-UX use the command "find /opt/VRTSvcs -perm 4755"

b. chmod u-s <binary name>

2. Restrict access to cluster nodes to only authorized VERITAS Cluster Server users

a. Check the value of cluster attribute AllowNativeCliUsers as:

i. haclus -value AllowNativeCliUsers

b. If the value of the above attribute is 1, perform the following steps:

i. haconf  -makerw

ii. haclus -modify AllowNativeCliUsers 0

iii. haconf -dump -makero

Force non-root users to specify a valid VERITAS Cluster Server username and password and use TCP for communication by setting the following environment variable:

c. VCS_TEST_HOST=<value> 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

Note:  By removing the root suid permissions, a non-root user cannot communicate with VERITAS Cluster Server 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 Cluster Server username and password.

WARNING: Any 'cron' jobs running as a non-root user and using a Cluster Server 'ha' command may fail because of not specifying a valid Cluster Server username and password. For such cases, the appropriate Cluster Server patch listed above should be applied.

As part of normal best practices, Symantec strongly recommends:

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

CVE

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.

Credit:

Symantec would like to thank Kevin Finisterre, for reporting this issue and for providing coordination while Symantec resolved it.