COMMAND

    /usr/lib/dmi/snmpXdmid

SYSTEMS AFFECTED

    Solaris

PROBLEM

    Job de Haas found following.   SNMP and DMI are remote  management
    protocols.   The snmpXdmid  mapper daemon  is used  on Solaris  to
    combine both worlds.  This daemon has an overflow in a buffer  for
    handling an 'indication'.  This 'indication' is sent to the daemon
    over RPC service 1000249.

    The buffer overflow can lead to local and remote root compromise.

    An exploit has been tested on  Solaris 8 sun4u.  However it  seems
    likely  hat  every  previous  version  is vulnerable including any
    security atches previously created.   The daemon was bundled  with
    Solaris 2.6, 7 and 8.

    The Desktop  Management Interface  (DMI) is  a management protocol
    designed  by  the  Desktop  Management  Task  Force  (DMTF).   Sun
    Microsystems  has  been   providing  a  daemon   based  on   these
    specifications  called  'dmid'  since  Solaris  2.6.  Further, Sun
    created a coupling between SNMP and DMI in the form of a so-called
    mapper daemon:

        /usr/lib/dmi/snmpXdmid

    This daemon  registers itself  with both  'snmpdx' and  'dmid' and
    translates SNMP requests to DMI.

    The mapper daemon shows  itself to the world  in two ways. On  one
    hand  it  registers  itself  with  'snmpdx'  as a subagent using a
    protocol called DPI.  It uses the UDP port 6500 for this.  On  the
    other hand  it registers  itself with  'dmid' using  the RPC based
    protocol of DMI.  This is found on Solaris as RPC service 1000249:

        ~> rpcinfo -p
        ...
            100249    1   udp  32785
            100249    1   tcp  32786
        ..

    This service is  a callback service  that allows 'dmid'  to report
    events back to 'snmpXdmid'.  These events are called 'indications'
    and are translated into SNMP traps.   By using one such event,  an
    overflow is  triggered.   More information  about the  XDR formats
    used  to  talk  to  the  'dmid'  daemon  can  be  found in the SDK
    available from Sun (ref. 1):

        /usr/include/dmi/common.h
        /usr/include/dmi/server.h
        /usr/include/dmi/ci_callback.h

    Further the callback specification for reporting back  indications
    can be found in:

        /opt/SUNWconn/sea/dmi/sample/miexample.h

    In  this  case  the  overflow  can  be  triggered  by  the   event
    DmiComponentAdded with  all fields  empty except  for the  name of
    the component the indication is  about.  This results in  a simple
    overflow in a memcpy in the daemon:

        =>[1] __align_cpy_1(0xfea0b590, 0xe15b4, 0x...
          [2] generateTrap(0xe0ae8, 0x0, 0x25438, 0x...
          [3] handle_CompLangGrpIndication(0x48400, 0xfea0bb70, 0x47b30,...
          [4] _dmicomponentadded_0x1_svc(0xfea0bb70, 0x49bb0, 0x...
          [5] dmi2_client_0x1(0x44a24, 0x24f58, 0x4443c, 0x...
          [6] _svc_prog_dispatch(0x2509c, 0x1, 0x0, 0xff21a...
          [7] svc_getreq_common(0xff21ebf0, 0x1, 0xff228778, 0x...
          [8] svc_getreq_poll(0x1, 0xb49d8, 0xff21ae30, 0x...
          [9] waitForIndication(0x48378, 0x1, 0x...

    From the trace above it  can be seen that the  indication received
    from 'dmid' is  translated into an  SNMP trap.   It is there  that
    the overflow occurs.

    From the way the daemon works it looks like it would be sufficient
    if it listened  solely on the  loopback interface or  used another
    form of local  transport to communicate.   This would make  remote
    attacks  on  the  daemon  much  more  difficult.   Also important,
    because it is  unknown if the  daemon provides any  authentication
    at all on messages received on both the SNMP interface as the  DMI
    interface.

SOLUTION

    For  99%  of  the  cases  the  daemon  can be safely turned off by
    turning off DMI completely.  This can be achieved by renaming

        /etc/rc?.d/S??dmi

    to

        /etc/rc?.d/K07dmi

    and  calling   '/etc/init.d/init.dmi  stop'   (where  ?   is   the
    appropriate runlevel).  It is also wise to remove all  permissions
    from the binary: chmod 000 /usr/lib/dmi/snmpXdmid

    Patches are expected shortly,  but no information is  available on
    an actual patch date.