Bugtraq mailing list archives
SNMP communities in 3Com HiPer Arcs (maybe other 3Com products?)
From: jeffm () IGLOU COM (Jeff Mcadams)
Date: Tue, 20 Jul 1999 13:59:09 -0400
Well...I hate doing this...but it can't be said that I didn't give them time to fix this...I first notified 3Com about this in early Feb. 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. I've 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. I have 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...I don't have access to other types of 3Com equipment to check. 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. 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 "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. Anyway...I first mentioned this to 3Com in early Feb. There has since then been a fairly major code release on the HiPer Arc code with no change to this problem (4.1.x -> 4.2.x). I did get an acknowledgement when I first posted the problem to 3Com that they were aware of it and working on it. Perhaps full disclosure will accelerate their work a bit. -- Jeff McAdams Email: jeffm () iglou com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Current thread:
- Re: Mail relay vulnerability in RedHat 5.0, 5.1, 5.2, (continued)
- Re: Mail relay vulnerability in RedHat 5.0, 5.1, 5.2 Ollivier Robert (Jul 19)
- Re: Mail relay vulnerability in RedHat 5.0, 5.1, 5.2 Matt Dunn (Jul 22)
- Re: Mail relay vulnerability in RedHat 5.0, 5.1, 5.2 Daniele Orlandi (Jul 24)
- Re: Shared memory DoS's Glynn Clements (Jul 16)
- Re: Shared memory DoS's Mike Perry (Jul 16)
- Re: Shared memory DoS's Howard Kaye (Jul 19)
- Samba 2.0.5 security fixes Andrew Tridgell (Jul 20)
- Re: Shared memory DoS's Richard Shetron (Jul 20)
- Delegate creates directories writable for anyone Olaf Seibert (Jul 21)
- Administrivia Aleph One (Jul 22)
- SNMP communities in 3Com HiPer Arcs (maybe other 3Com products?) Jeff Mcadams (Jul 20)
- Correction to Microsoft Security Bulletin MS99-025 aleph1 () UNDERGROUND ORG (Jul 20)