Re: [Ethereal-users] Re: Question about [Malformed Packet: SNMP] in SNMP Get-Next-Request

[Andrew Hood <ajhood@xxxxxxxxx>]

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