[jose.quinto@xxxxxxxxxxxxxxx]

The SNMP Agent im using is a network board of a multi-function peripheral
(printer-scanner-fax-copier-in-one) of Muratec systems, Japan.
I'm doing an improvement in the current SNMP implementation of
the network board's firmware to enable faster processing and to be flexible
for future changes/support.

I've tried changing the size of the encoded length to 2 or more bytes
but it sometimes produces a NOSUCHNAME error.

To Wes Hardaker, what do you mean the manager is broken as well?
Im using my PC as the host and an the snmp monitor is
SnmpMonitor version 1.0.4(2004/05/29) Copyright(C) 2003-2004 milu
(http://www.milu.jp/SnmpMonitor/)

I'm wondering if there is a problem in the implementation of the
GetifSpecific function
in the codes, the function is the responsible for the setting of the
response data.

Thank you in advance for the responses.


============================
Jose Vicente R. Quinto　ジョビク
ADTX Systems, Inc.
Phone:  +632-8075521
Mobile:  +63-9186377008
============================




------------------------------

Message: 2
Date: Wed, 02 Feb 2005 21:40:06 +1100
From: Andrew Hood <ajhood@xxxxxxxxx>
Subject: Re: [Ethereal-users] Re: Question about [Malformed Packet:
           SNMP]          in        SNMP Get-Next-Request
To: Ethereal user support <ethereal-users@xxxxxxxxxxxx>
Message-ID: <4200AE06.1000009@xxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

Someone with a bit more ASN.1 encoding experience may wish to comment on
my analysis.

jose.quinto@xxxxxxxxxxxxxxx wrote:
> To ethereal users,
>
> I'm encountering one SNMP Get-Next request
> with a [Malformed Packet: SNMP] in it.
>
> The request in the captured data file attached is at
>
> 117  ....   SNMP   RESPONSE  IF-MIB::ifSpecific.1[Malformed Packet]
> ...   << up to >>
> 120  ....   SNMP   GET-NEXT  IF-MIB::ifSpecific.2[Malformed Packet]
>
> I wonder why is this happening, even if i test the GET request, it still
> has a malformed packet
> in the ifSpecific part also.
>
> Please refer to the attached captured file for the details.
>

It would have been a bit simpler if you had only included the SNMP traffic.

Your first malformed packet is:

0000  00 11 2f 27 de d6 00 50 81 20 00 00 08 00 45 00   ../'...P. ....E.
0010  00 47 00 38 00 00 40 11 4c 8b c0 a8 d6 4f c0 a8   .G.8..@.L....O..
0020  d6 42 00 a1 05 b1 00 33 ab d4 30 29 02 01 00 04   .B.....3..0)....
0030  06 70 75 62 6c 69 63 a2 1c 02 01 34 02 01 00 02   .public....4....
0040  01 00 30 11 30 0f 06 0a 2b 06 01 02 01 02 02 01   ..0.0...+.......
0050  16 01 06 01 d0                                    .....

The bit Ethereal considers malformed is the last 3 bytes - 06 01 d0
06 - ASN.1 type OID
01 - encoded length is 1 byte
d0 - the OID value

d0 has the high bit set, meaning there should be more bytes to the
subidentifier but the data has length 1, hence the packet is malformed.
In an SNMP process with less strict parsing this may produce a buffer
overflow.

There are other errors which you may not have noticed.

IF-MIB::ifSpeed is returning INTEGER and should be Gauge32 or Unsigned32.

What is the SNMP agent?

--
There's no point in being grown up if you can't be childish sometimes.
                -- Dr. Who


------------------------------

Message: 5
Date: Wed, 02 Feb 2005 09:13:42 -0800
From: Wes Hardaker <wjhns36@xxxxxxxxxxxxx>
Subject: [Ethereal-users] Re: Question about [Malformed Packet: SNMP]
           in        SNMP Get-Next-Request
To: Ethereal user support <ethereal-users@xxxxxxxxxxxx>
Message-ID: <sdmzumkhq1.fsf@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

>>>>> 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.

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.

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.

# snmptranslate -Ib -Td ifSpecific
IF-MIB::ifSpecific
ifSpecific OBJECT-TYPE
  -- FROM       IF-MIB, RFC1213-MIB
  SYNTAX        OBJECT IDENTIFIER
  MAX-ACCESS    read-only
  STATUS        deprecated
  DESCRIPTION   "A reference to MIB definitions specific to the particular
            media being used to realize the interface.  It is

            recommended that this value point to an instance of a MIB
            object in the media-specific MIB, i.e., that this object
            have the semantics associated with the InstancePointer
            textual convention defined in RFC 2579.  In fact, it is
            recommended that the media-specific MIB specify what value
            ifSpecific should/can take for values of ifType.  If no MIB
            definitions specific to the particular media are available,
            the value should be set to the OBJECT IDENTIFIER { 0 0 }."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) interfaces(2)
ifTable(2) ifEntry(1) 22 }

--
Wes Hardaker
Sparta



------------------------------

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users


End of Ethereal-users Digest, Vol 22, Issue 3
*********************************************