Re: [Wireshark-commits] rev 37826: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-rpcap.c

[Guy Harris <guy () alum mit edu>]

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.

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.

A packet could be synthesized that would pass the heuristics and still end up spinning for a very long time in that 
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?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe