Vulnerability

    SNMP

Affected

    SNMP communities in 3Com HiPer Arcs (other 3Com products?)

Description

    Jeff Mcadams found  following.  The  3Com HiPer Arc  cards are the
    new generation access  server cards for  the Total Control  Access
    Server system.  These cards use the "Pilgrim" code base for  their
    software.  Jeff  has been told  by some people  at 3Com that  this
    code base is going to be  the code that, eventually, all of  their
    routing  products   will  be   running.    Jeff  has    experience
    specifically with HiPer Arcs in Total Control racks...but  because
    the code  base that  is commonly  called "Pilgrim"  is shared with
    several  other  products  within  3Com   (and  soon  to  be   more
    apparently) this problem might  be more widespread...   The impact
    is that anyone  with any SNMP  access to the  box is likely  to be
    able  to  elevate  their  access  to  the  highest level of access
    defined on the box.

    There are three levels of  access on HiPer Arcs...read only,  read
    write,  and   administrative.   The   crux  of   the  problem   is
    simple...the usrSnmpCommAccess and  other related SNMP  tables and
    values are fully readable by  all access levels.  This  means that
    someone with a read-only  community string can read  the community
    table and see what read-write and administrative community strings
    are defined on the system to be used.

Solution

    There  are  several  workarounds.   First,  the  Arcs allow you to
    specify specific IP addresses or IP address pools from which  SNMP
    access will be allowed for  each community string.  Setting  these
    restrictions will restrict  access for specific  community strings
    for specific hosts, which...while not being great, is better  than
    nothing.  This also still allows the other community strings to be
    readable, if  not useable,  and could  possibly be  used in  other
    places.   The  other  workaround  is  to  not define any community
    strings on the Arcs at all.   SNMP access can still be granted  to
    the Arc,  just not  directly.   The Total  Control access  systems
    have a Network Management Card which is used for most SNMP  access
    to the Total Control components.  The Arc has its own agent, other
    cards use the NMC  card for their agent.   The NMC can be  used as
    an SNMP relay agent  on behalf of the  Arcs.  The procedure  to do
    this is to specify the NMC's community string with  "@<entitynum>"
    appended on the  end.  <entitynum>  is a value  used internally in
    the chassis to  refer to specific  components of the  system.  For
    example, the  card in  slot 16  (typically the  HiPer Arc)  has an
    entitynum of 16000.  The card  in slot 5 would be an  entitynum of
    5000.   The  third  modem  on  the  card  in  slot  5  would be an
    entitynum  of  5003.   So,  to  send  an  SNMP command to the Arc,
    assuming its in slot 16,  and assuming an NMC community  string of
    "public" for example purposes,  you'd use the community  string of
    "public@16000".  The only real drawback to this workaround is  the
    extra load that is  put on the NMC  cards (many of which  are only
    486  processor  based...none-too-overpowered),  and  that the SNMP
    operations  are  slowed  down  by  having  to be processed through
    another system.