Could have guessed Wes (or David or Dave) would add some wisdom :-)
Wes Hardaker wrote:
On Wed, 02 Feb 2005 21:40:06 +1100, Andrew Hood <ajhood@xxxxxxxxx> said:
Andrew> The bit Ethereal considers malformed is the last 3 bytes - 06 01 d0
Andrew> 06 - ASN.1 type OID
Andrew> 01 - encoded length is 1 byte
Andrew> d0 - the OID value
Andrew> d0 has the high bit set, meaning there should be more bytes to
Andrew> the subidentifier but the data has length 1, hence the packet
Andrew> is malformed. In an SNMP process with less strict parsing
Andrew> this may produce a buffer overflow.
Actually, no. The first two numbers of an OID (A.B) is actually the encoded
into the first byte using a value of A * 40 + B. Thus what is
normally the first 2 numbers of most oids (1.3) is actually the first
byte in any OID as 43 = 0x2b. d0 is then the OID 5.8. Now, the only
thing I'm not positive about is if the high bit is allowed to be used
in this way or if it extends the first byte as well. I'd have to go
look up a reference book to remember that. If that's the case, that's
certainly the problem.
I tried following how net-snmp checks it in asn1.c :-). I *think* this
is how it works. It has a do loop with the test for the top bit set and
more data remaining. So this looks like it should be 80<<7 + whatever is
in the missing byte (repeating if that has the top bit set).
In the encoded byte, asn1.c treats anything bigger that 80 as
.2.(value-80). If the code is wrong and in the first octet it should not
treat the top bit as "more data" then this would make it .2.128
Note that in this case the manager is broken as well, because it's
sending the GETNEXT response back with the value still in place. This
is actually illegal because it should be replacing the value with a
NULL (BER: 05 00) value instead.
I noticed that too, but wasn't sure if this behaviour was acceptable.
Andrew> IF-MIB::ifSpeed is returning INTEGER and should be Gauge32 or
Andrew> Unsigned32.
column 22 is actually ifSpecific, not ifSpeed. And it's value should
be an OID.
It wasn't that packet. There are ifSpeed responses in other packets, and
they are encoded INTEGER.
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who