UPDATE: Cert Advisory 2002-03 and Ethereal

[Information Security <InformationSecurity () federatedinv com>]

The Ethereal development team responded to concerns about SNMP with the
following message.  After providing them with a copy of the malformed
packet, Guy was able to confirm that it does not crash the current CVS
version of Ethereal.


-----Original Message-----
From: Guy Harris [mailto:guy () netapp com]
Sent: Monday, February 25, 2002 4:32 PM
To: Faber, Sidney
Cc: 'ethereal-dev () ethereal com'; 'david evlis reign'
Subject: Re: [Ethereal-dev] Cert Advisory 2002-03 / SNMP


On Mon, Feb 25, 2002 at 04:18:01PM -0500, Faber, Sidney wrote:
> Perhaps you've heard of the recent SNMP issues surrounding CERT advisory
> 2002-03 (http://www.cert.org/advisories/CA-2002-03.html).  I was working
> with the tool to test HP printers, and found a malformed SNMP packet that
> killed HP JetDirect cards.  I wanted to take a look at the packet, so I
> pulled up my trusty copy of Ethereal (thank you!), and found that it also
> choked on the packet.  Whenever it is decoded for display, I get a dialog
> box "GLib-ERROR **: could not allocate -1 bytes aborting...".  

A change that should fix that has already been checked in, and should
appear in the next release.

> I can forward you the capture file individually if it might help, or
direct
> you on where to get a copy of Protos.

Send me a copy of the packet; that'd make testing the fix to make sure
it actually fixes the problem much easier than would having to run
Protos.

> The bug in Ethereal itself doesn't worry me, since it was a bogus packet
to
> begin with.  But I'm in information security (ie, paranoid), and I'm
hoping
> the bug itself is limited to Ethereal, and not to one of the support
> libraries, and also wouldn't lead to an exploitable buffer overflow.

That particular bug is limited to Ethereal.  However, it's in code that
we picked up from GXSNMP and then modified; I'll check to see whether
the original code also runs the risk of trying to allocate a truly huge
chunk of memory if a {bit string, octet string, OID, etc.} item has a
BER length of 0xffffffff (or an otherwise huge length), or if the memory
allocation is something we added.

> -----Original Message-----
> From: david evlis reign [mailto:davidreign () hotmail com]
> Sent: Friday, February 22, 2002 5:14 AM
> To: bugtraq () securityfocus com
> Subject: Re: Cert Advisory 2002-03 and HP JetDirect 
>
>
> As an interesting side note, Ethereal (a popular open source sniffer /
> traffic analyzer) crashes every time it sees this packet also. It gives
the
> error "GLib-ERROR **: could not allocate -1 bytes aborting...".
>
> this caught my attention for two reasons.
> my probably wrong explantion for this is the following:
> 1) mangled packet sent, containing some large values (no idea what)
> 2) ettercap recieves and processes this saying that int whatever = <large 
> value from packet>
> 3) int returns unsigned, classic integer overflow style.
> 4) passed to malloc as an unsigned value, malloc shits itself.
> 5) ettercap spits out cant allocate <whatever> bytes.

(I've no idea what "ettercap" is; I assume he means Ethereal.)

The problem is that the BER length of the field is 0xffffffff (I suspect
they're unsigned values, not signed, although I don't have the ASN.1
specs handy, so maybe there *are* meaningful negative values for those
lengths), and so we pass 0xffffffff as a length to "g_malloc()", and
that allocation fails.  It'd probably fail on at least some platforms
regardless of whether it's signed or unsigned, so signed vs. unsigned is
irrelevant.

The fix, in Ethereal, is to check to see whether the entire object, with
the specified length, is contained within the buffer from which we'd
extract it.  If not, we'd throw an exception anyway (causing Ethereal to
report a "Short Frame" or "Malformed Packet" or "Unreassembled Packet),
so, before allocating the buffer, we attempt to fetch the last byte of
the object - that attempt will throw the exception in question.

In addition, we *also* check to make sure that the offset in the buffer
past the end of the object, which is the sum of the offset in the buffer
of the beginning of the object and the length of the object, is either
negative or before the beginning of the object (although the first check
is actually redundant, as offsets shouldn't be negative) - if so, we
assume that the length was large enough that we overflowed, and we set
the length to INT_MAX, which means that the object will be treated as
very large, so the attempt to fetch the last byte will get an exception,
again preventing us from doing the bad malloc.