1. Symantec/
  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


October 20, 2008

Revision History




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

*Proof of concept only


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

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


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:

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.


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


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.
Symantec has developed a Software Security Vulnerability Management Process document outlining the process we follow in addressing suspected vulnerabilities in our products.
Symantec Corporation firmly believes in a proactive approach to secure software development and implements security review into various stages of the software development process. Additionally, Symantec is committed to the security of its products and services as well as to its customers’ data. Symantec is committed to continually improving its software security process.
This document provides an overview of the current Secure Development Lifecycle (SDLC) practice applicable to Symantec’s product and service teams as well as other software security related activities and policies used by such teams. This document is intended as a summary and does not represent a comprehensive list of security testing and practices conducted by Symantec in the software development process.
Please contact secure@symantec.com if you believe you have discovered a security issue in a Symantec product. A member of the Symantec Software 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 Software Security PGP key can be found at the following location:
Permission to redistribute this alert electronically is granted as long as it is not edited in any way unless authorized by Symantec Software Security. Reprinting the whole or part of this alert in any medium other than electronically requires permission from secure@symantec.com.
Last modified on: October 20, 2008
Security Response Blog
The State of Spam