8076041 2002-02-27 08:53 -0500 /101 rader/ Information Security <InformationSecurity@federatedinv.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-01 11:20 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21212>
Ärende: UPDATE: Cert Advisory 2002-03 and Ethereal
------------------------------------------------------------
From: Information Security <InformationSecurity@federatedinv.com>
To: bugtraq@securityfocus.com
Message-ID: <D5E5F4682E75D41185CD00D0B79DC56F04BB1AB8@exchfed01.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.
(8076041) /Information Security <InformationSecurity@federatedinv.com>/(Ombruten)