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 $ ./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.