SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Generic)  >   Wireshark Vendors:   Wireshark.org
(Current Version is Not Vulnerable) Re: Ethereal SNMP Processing Bug Lets Remote Users Crash the Network Sniffer
SecurityTracker Alert ID:  1003711
SecurityTracker URL:  http://securitytracker.com/id/1003711
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Mar 1 2002
Impact:   Denial of service via network
Fix Available:  Yes  Vendor Confirmed:  Yes  

Description:   A denial of service vulnerability has been reported in the Ethereal network sniffing software. A remote user can cause the application to crash.

SecurityFocus has reported a denial of service vulnerability and a potential buffer overflow vulnerability in the Ethereal packet sniffer.

According to the report, a remote user can created a specific malformed SNMP packet that will cause Ethereal to crash when it reads the packet. The report also indicates that this behavior may be due to a buffer overflow that may potentially be exploitable (however, that has not been confirmed).

This vulnerability can reporteldy be triggered using the Protos SNMP test "set-req-ber-l-length" in the category of "Invalid BER length (L) fields."

This information is based on a Feb 19 2002 message from Information Security <informationsecurity@federatedinv.com>.

Impact:   A remote user can cause the Ethereal sniffer to crash. A remote user may be able to execute arbitrary code on the sniffer (however, that has not been confirmed).
Solution:   It is reported that the current CVS version of Ethereal is not vulnerable. Upgrade to the current version, available at the Vendor URL.
Vendor URL:  www.ethereal.com (Links to External Site)
Cause:   Not specified
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   This archive entry is a follow-up to the message listed below.
Feb 25 2002 Ethereal SNMP Processing Bug Lets Remote Users Crash the Network Sniffer



 Source Message Contents

Subject:  UPDATE: Cert Advisory 2002-03 and Ethereal


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.

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2022, SecurityGlobal.net LLC