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.
