1. /
  2. Security Response/
  3. Security Updates Detail

Security Advisories Relating to Symantec Products - Veritas File System Quick I/O for Database Utility Information Disclosure and Elevation of Privilege

SYM08-018

October 20, 2008

Revision History

None

Severity

Medium

Remote Access (adjacent network)No
Local AccessYes
Authentication RequiredYes
Exploit publicly availableNot Required



*Proof of concept only

Overview

A potential for sensitive information to be disclosed has been identified and resolved in the Quick I/O for Database feature of Veritas File System (VxFS). Quick I/O for Database is a mechanism allowing fast concurrent access to improve performance.

Affected Products

ProductVersionPlatformSolution(s)
Veritas File System (VxFS)All SupportedSolaris, Linux, AIX5.0 MP3 http://entsupport.symantec.com/docs/310872
Veritas File System (VxFS)All SupportedHP-UXSee Recommended Workarounds

Details

Security Objectives notified Symantec of the potential for unauthorized information disclosure in the Quick I/O for Database feature in VxFS.

The first issue is the exposure of uninitialized file system blocks (which may contain sensitive information) by the qiomkfile command. The qiomkfile command allocates file system blocks to a new file without initializing those blocks, so the contents of the blocks becomes readable by any user that can read the new file. This is intended to be a performance optimization for databases, but if those blocks formerly belonged to a file containing sensitive information, then that information can be accessed via the new file that now owns the blocks. The VxFS operation performing this allocation without initialization is restricted to privileged users, but the qiomkfile command is set-uid root so non-privileged but authorized users could potentially circumvent the security restriction on the allocation operation by using this command.

A second issue is an unauthorized file content disclosure in the qioadmin utility for the Quick I/O for Database feature. A user with authorized system access and sufficient privileges to run the qioadmin utility can supply any filename of a file on the system to qioadmin and redirect the file content to standard error. The qioadmin utility is set-uid root which could allow non-privileged but authorized users to circumvent system file permission restrictions to gain access to privileged system information.

In Symantec’s recommended installation an affected system should have limited or no exposure to the general internal network and no exposure outside of the corporate network which greatly reduces the risk of unauthorized access.

Symantec Response

Symantec Engineers have verified and resolved these issues.

Symantec recommends customers apply the latest product update available for their supported product versions to enhance their security posture and protect against potential security threats of this nature.

Symantec knows of no exploitation of or adverse customer impact from this issue.

Additional information concerning updates for affected products can be found at:
http://entsupport.symantec.com/docs/310872

Recommended Workarounds

If a customer is unable to or chooses not to apply the recommended update at this time, the following workarounds are applicable:
  • Workaround for the qioadmin file disclosure issue:
    ‘chmod u-s /opt/VRTS/bin/qioadmin’
  • Workarounds for the qiomkfile uninitialized file system block issue:
    To only allow root users to execute this utility remove the set-uid flag for qiomkfile
    ‘chmod u-s /opt/VRTS/bin/qiomkfile’
  • To retain set-uid root for qiomkfile but restrict group execute permissions to some particular Unix group, e.g., “oracledba” group will not be able to use qiomkfile.
    1. ‘chgrp oracledba /opt/VRTS/bin/qiomkfile’
    2. ‘chmod 4750 /opt/VRTS/bin/qiomkfile’

    Under this workaround, Users in the "oracledba" group will still be able to run qiomkfile effectively, but users that aren’t in the “oracledba” group will not be able to use qiomkfile.

    NOTE: since the blocks in the files that qiomkfile creates will still be uninitialized, those files should have permissions such that only trusted users will be able to access them. 3. Turn off the flag for qiomkfile (as in workaround 1 above) and use a utility like “sudo” to give individual users or groups permission to execute qiomkfile as root. this is similar to workaround 2, but the access control mechanism of sudo is more flexible than that of Unix permissions.

Best Practices

As part of normal best practices, Symantec strongly recommends:
  • Restrict access to administration or management systems to privileged users.
  • Restrict remote access, if required, to trusted/authorized systems only.
  • Keep all operating systems and applications updated with the latest vendor patches.
  • Follow a multi-layered approach to security. Run both firewall and anti-malware applications, at a minimum, to provide multiple points of detection and protection to both inbound and outbound threats.
  • Deploy network and host-based 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.

Credit

Symantec would like to thank Derek Callaway with Security Objectives for reporting these issues and for providing full coordination while Symantec resolved them.

References

SecurityFocus has assigned a Bugtraq ID (BID) to these issues for inclusion in the SecurityFocus vulnerability data base. BID 31678 has been assigned to the qiomkfile uninitialized file system blocks issue and BID 31679 to the qioadmin unauthorized file disclosure issue. The BIDs can be found at http://www.securityfocus.com/bid/31678 and http://www.securityfocus.com/bid/31679.

These issues are candidates for inclusion in the Common Vulnerabilities and Exposures (CVE) list (http://cve.mitre.org), which standardizes names for security problems. CVE-2008-3248 has been assigned to the qiomkfile uninitialized file system blocks issue.

A CVE Candidate number has been requested from the Common Vulnerabilities and Exposures (CVE) initiative for the qioadmin issue. This advisory will be revised accordingly upon receipt of the CVE Candidate number.
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 responsible disclosure guidelines.
Please contact secure@symantec.com if you feel you have discovered a security issue in a Symantec product. A member of the Symantec Product Security team will contact you regarding your submission to coordinate any required response. Symantec strongly recommends using encrypted email for reporting vulnerability information to secure@symantec.com. The Symantec Product Security PGP key can be found at the location below.
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) 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 Product Security. Reprinting the whole or part of this alert in any medium other than electronically requires permission from secure@symantec.com

Disclaimer

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 Product Security, and secure@symantec.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.
* Signature names may have been updated to comply with an updated IPS Signature naming convention. See http://www.symantec.com/business/support/index?page=content&id=TECH152794&key=54619&actp=LIST for more information.
Last modified on: October 20, 2008
Security Response Blog
The State of Spam