COMMAND
Sun Cluster
SYSTEMS AFFECTED
Sun Cluster 2.x
PROBLEM
Dixie Flatline found following. Sun Cluster 2.x (Sun
Microsystems' commercial high-availability product for Solaris)
leaks potentially sensitive information to local or remote users.
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.
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.
There is another hole as well. 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.
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 first
hole, 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 ...
SOLUTION
One could trivially use tcp wrappers to keep unauthorized hosts
away from the port in question. According to Sun support "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.
As for second hole, change the permissions on the files in
question. Use tcp wrappers to keep unauthorized hosts away from
in.mond. Sun is investigating second hole.