Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 37826: /trunk/epan/dissectors/ /trun
From: Stig Bjørlykke <[email protected]>
Date: Wed, 29 Jun 2011 10:20:50 +0200
On Wed, Jun 29, 2011 at 9:47 AM, Guy Harris <[email protected]> wrote:
> On Jun 29, 2011, at 12:04 AM, Stig Bjørlykke wrote:
>> I have strengthened the heuristics in revision 37828, which seems to
>> really fix the problem.
> Well, it fixes the problem with that *particular* capture.

Sure, but it does the exact check as in dissect_rpcap_packet() and
discards the message before it's recognized as RPCAP.

> The underlying problem is that proto_tree_add_item() might not end up doing anything that checks the validity of the offset, so if nitems in dissect_rpcap_filter() has an absurdly large value, the loop in dissect_rpcap_filter() can go well past the end of the packet and only stop when it's put "too many" items into the protocol tree - unfortunately, "too many" is large enough that this could take a while.

Then we also want to add a sanity check for nitems, to avoid a
absurdly large loop.

>> The offset calculations was left on purpose, to easy extend the dissector later.
> OK, so what should dissect_rpcap_packet() return in the case where the caplen value is bogus?

0, as in nothing decoded when registered as a "new" dissector, as the
very first version (from revision 26633) of the dissector.  I wanted
to keep the offsets so we can use the dissector as "new" again.  I
have a long term project, which depends on whether libpcap will
support rpcap :)

Stig Bjørlykke