>>>>> "rd" == Ron DuFresne <dufresneat_private> writes: rd> On Wed, 20 Feb 2002, Wes Hardaker wrote: >> >>>>> On Tue, 19 Feb 2002 09:39:29 +0000, "david evlis reign" <davidreignat_private> said: >> david> http://www.phrack.org/show.php?p=50&a=7 >> david> four years old and you think this is a *new* problem, exploit david> code/exploit tools/exploit inormation has been floating around for david> years. >> >> Oh please, that's just describing the vulnerabilities everyone knows >> exists with SNMPv1. Switch a secure version of the protocol (like it >> even suggests in the document) and everything stated there goes away. >> The document describes none of the problems that everyone is talking >> about this month. rd> Would not a more secure version of snmp be snmpv2 or snmpv3? If so, then rd> the cert advisory is dealing with snmpv1 from what I read: rd> Afterall, most vendors still impliment snmpv1 for compatability issues do rd> they not? Especially those hardcoded implementations such as those rd> coming out on old HP directjet cards and such, yes? Perhaps I'm as wrong rd> as David in this, and am certainly up to being corrected. All SNMPvX implementations have to support v1 for compatibility. They should all turn it off, but "should" is a mighty weak word. Also, all versions of SNMP are BER encoded. The libraries used to BER encode/decode SNMPv1 PDUs are the same libraries used to encode/decode SNMPv2/SNMPv3 PDUs. Sure, with v3 you can't sniff the community string, but you can still send devices packets that are not decodable. And if those devices use the same libs that have been causing so much happiness with v1 implementations, then you'll have the same problems with v2 and v3. Basically, the enc suite of tests, rather than app, still applies. ericb -- Eric Brandwine | The probability that we may fail in the struggle ought UUNetwork Security | not to deter us from the support of a cause we believe ericbat_private | to be just. +1 703 886 6038 | - Abraham Lincoln Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
This archive was generated by hypermail 2b30 : Thu Feb 21 2002 - 17:08:35 PST