It appears more than one vendor shared the same SNMP library (or
SNMP programmer). Folks have sent me evidence at least two other
vendor's equipment has similar responses to the same SNMP community
string ILMI.
However, there are other non-related SNMP issues. Many SNMP
implementations included the default community strings "public"
and "private". If the operator doesn't change them, the defaults
may still work. The other common SNMP implementation issue is if
no community string is specified, the SNMP agent accepts any
community string.
If you are checking your network, I'd suggest checking for all
three possibilities.
IMHO, if no communities are supplied, the SNMP daemon should not respond
at all.
While I agree that "public" and "private" are "wellknowns," in most
implementations, they at least show up in the code. Cisco chose to hide
this one where it would not show up in the code. That IMHO is a very bad
thing and does bad things to my confidence level in Cisco.
>
> It appears more than one vendor shared the same SNMP library (or
> SNMP programmer). Folks have sent me evidence at least two other
> vendor's equipment has similar responses to the same SNMP community
> string ILMI.
>
> However, there are other non-related SNMP issues. Many SNMP
> implementations included the default community strings "public"
> and "private". If the operator doesn't change them, the defaults
> may still work. The other common SNMP implementation issue is if
> no community string is specified, the SNMP agent accepts any
> community string.
>
> If you are checking your network, I'd suggest checking for all
> three possibilities.
>
>
>
IMHO, if no communities are supplied, the SNMP daemon should not respond
at all.
While I agree that "public" and "private" are "wellknowns," in most
implementations, they at least show up in the code. Cisco chose to hide
this one where it would not show up in the code. That IMHO is a very bad
thing and does bad things to my confidence level in Cisco.
Please, stop the damn FUD, how do you know it wasn't accidentally left
in by a programmer doing debugging? I bet you assume all buffer overflows
are purposely put in also, eh? Sure. I expect it to cut back on your
confidence in Cisco IOS, but also, what's this noise about code? Do you
happen to have a hold on IOS source code or something that you personally
audit?
While I agree that "public" and "private" are "wellknowns," in most
implementations, they at least show up in the code. Cisco chose to hide
this one where it would not show up in the code. That IMHO is a very bad
thing and does bad things to my confidence level in Cisco.
Do a "show snmp group" from an enabled console prompt. It does show.
I expect an organization as large as Cisco, with a QA section as large as
Ciscos to NOT leave things accidentally in code.
Buffer overflows, while APIMA, are accidental in nature, sometimes brought
on by incompetence, more often brought on my inexperience.
As for having IOS source, no, I don't. I won't even say that if I did
have access to the source I would have found it. I do know that if the
source was open, it would have been found much earlier and I will say that
every decent programmer that has put things in code for degugging COMMENTS
such code in a manner that it is easy to grep and remove.
In Ciscos defence, it appears that the ILMI community is there for ATM
functionality. It would have been nice for them to have noticed this
"feature" in the SNMP implementation and caused the code to add it to the
config where it was PLAINLY visible.
Basically, someone, perhaps many people, knew about this issue and did not
act on it. This is not IMHO the proper way to treat a security issue.
It has already been stated that the damage caused by this "feature" is
limited. _ANY_ unauthorized changes to router configs is a VERY BAD thing
though and as such, this is a VERY BAD thing.
I appreciate your direct approach. In the future, I would also appreciate
your not cursing me. I don't know you. You don't know me. Lets be
professional, OK?