Vulnerability

    Sun Cluster

Affected

    Sun Cluster 2.x

Description

    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.