Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 2141] Buildbot crash output: fuzz-2007-12-26-32600.pcap

Date: Thu, 27 Dec 2007 08:25:11 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2141





------- Comment #1 from jyoung@xxxxxxx  2007-12-27 08:25 GMT -------
This is bug in the PCE dissector.

NOTE: I suggest setting a gdb breakpoint at file.c:1009 (the line: "row =
packet_list_append(cf->cinfo.col_data, fdata);".

If execution is allowed to continue into packet_list_append() with the data
returned from the PCE dissector there is a very good chance you will have a
hard time getting control back from a runaway Wireshark.

If you set the breakpoint you will most likely not lock up your machine and you
 probably see this warning message:

> Warn Dissector bug, protocol PCE, in packet 1: More than 1000000 items in the tree 
-- possible infinite loop

This particular bug is triggered in the dissect_pce_iro_obj() function of
packet-pce.c.  

Specfically the problem is in the loop that starts at packet-pce.c:1532

>        while(body_obj_len){
>
>        l_type = tvb_get_guint8(tvb, *offset2);
>        length = tvb_get_guint8(tvb, *offset2+1);

While dissecting the referenced fuzz file, the tvb's *offset2+1 results in the
length variable getting set to a value of 0 (zero).

Subsequent code in the loop doesn't account for a zero value for the length
variable.  Consequently the loop doesn't exit by itself.   Eventually a
DissectorError is triggered/caught by packet-frame.c which results in the "Warn
Dissector bug" message reported above.  

After the DissectorError is generated control returns back to the
add_packet_to_packet_list() function in file.c. 

I see a couple possible ways to fix to the packet-pce.c's dissect_pce_iro_obj()
inifinite loop if length == zero problem:

Probably the the most obvious is at the top of the loop to explicitly check
check the variable "length" for a value of zero and gracefully exit the
dissector (with an appropriate message).   

Another possibility is to add a test for the zero "length" value in the
"default:" case of the subsequent "switch(type_iro) {" (since the default: case
is what the fuzzed data presented).  But this second approach would not stop
the progagation of the zero "length" value to the dissectors called for various
non-default cases.  Perhaps those others dissectors already safely can
handle/expect a zero "length" variable.

I hope someone finds this info useful.



-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.