Wireshark-dev: Re: [Wireshark-dev] Finding the bug in the unistim dissector
From: "Luis EG Ontanon" <luis.ontanon@xxxxxxxxx>
Date: Wed, 15 Aug 2007 20:47:52 +0200
Might be a buffer overflow overwriting it. - break after protocol registration. - find the object that gets altered, - set a watchpoint on that memory location - continue until the watchpoint tells you who and where it gets overwritten. Luis On 8/15/07, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote: > Hi list, > > I've picked up the unistim dissector a while ago and try getting it into > shape for checkin. Thing is that I'm currently running fuzztests which > for the most run fine, but now I've isolated a packet that causes a > segmentation fault. The problem is that I'm stuck looking for the cause. > > When running Wireshark in DDD I find that the segfault occurs while > priming the display filter. This is the start of the backtrace: > > #0 0xb6da2a46 in fvt_cache_cb (node=0x8a86a20, data=0x0) at > dfilter-macro.c:66 > #1 0xb6d659d3 in proto_tree_traverse_in_order (tree=0x8a86a20, > func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:478 > #2 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a86ac8, > func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 > #3 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37038, > func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 > #4 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37398, > func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 > #5 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a373f8, > func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 > #6 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37980, > func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473 > #7 0xb6da2a0f in dfilter_macro_build_ftv_cache (tree_root=0x8a37980) at > dfilter-macro.c:87 > #8 0x080707e0 in cf_select_packet (cf=0x81974c0, row=0) at file.c:3256 > #9 0x0808db1a in packet_list_select_cb (w=0x8866010, row=0, col=-1, > evt=0x0) at packet_list.c:284 > > which leads to > --------------8<------------- > static gboolean fvt_cache_cb(proto_node * node, gpointer data _U_) { > field_info* finfo = node->finfo; > fvt_cache_entry_t* e; > > if (!finfo) return FALSE; > > if ((e = g_hash_table_lookup(fvt_cache,finfo->hfinfo->abbrev))) > --------------8<------------- > > Where finfo->hfinfo proves to be 0x8. How does it get that value? > > When running Tshark I get most of the output: > > Frame 1 (124 bytes on wire, 124 bytes captured) > Ethernet II, Src: Cisco_1d:c9:c0 (00:13:80:1d:c9:c0), Dst: > Nortel_ff:c8:66 (00:13:65:ff:c8:66) > Internet Protocol, Src: 131.253.0.203 (131.253.0.203), Dst: 10.64.50.150 > (10.64.50.150) > User Datagram Protocol, Src Port: commplex-main (5000), Dst Port: 22408 > (22408) > UNISTIM Protocol > Reliable UDP > RUDP Seq Num: Normal Sequence Number (0x0000dbb4) > RUDP Pkt type: Payload (2) > UNISTIM Payload: Aggregate Unistim (0x01) > Unistim CMD > UNISTIM CMD Address: Display Manager Switch (0x17) > UNISTIM CMD Length: 5 > Display Cmd (switch): Clear Field (0x0f) > 0001 0000 = FLAGS: For Following Byte > .... ...0 = Numeric Index Field in InfoBar: False > .... ..0. = Context Field in InfoBar: False > .... .0.. = Date Field: False > .... 0... = Time Field: False > ...1 .... = Line Data: True > ..0. .... = Status Bar Icon: False > .0.. .... = Soft Key: False > 0... .... = Soft Key Label: False > 1111 1111 = FLAGS: For Following Byte > .... ...1 = Line 1: True > .... ..1. = Line 2: True > .... .1.. = Line 3: True > .... 1... = Line 4: True > ...1 .... = Line 5: True > ..1. .... = Line 6: True > .1.. .... = Line 7: True > 1... .... = Line 8: True > Unistim CMD > UNISTIM CMD Address: Display Manager Switch (0x17) > UNISTIM CMD Length: 15 > Display Cmd (switch): Display Data Write address|yes > control|no tag|no (0x19) > Address > 0000 0100 = FLAGS: For Following Byte > .... ...0 = Is Address Numberic: False > .... ..0. = Context Field in the Info Bar: False > .... .1.. = Write A Line: True > .... 0... = Write a SoftKey: False > ...0 .... = Write A Softkey Label: False > 000. .... = Line Number: 0 > DATA: 4. Feature > Unistim CMD > UNISTIM CMD Address: Display Manager Switch (0x17) > UNISTIM CMD Length: 16 > Display Cmd (switch): Display Data Write address|yes > control|no tag|no (0x19) > Address > 0000 0100 = FLAGS: For Following Byte > .... ...0 = Is Address Numberic: False > .... ..0. = Context Field in the Info Bar: False > .... .1.. = Write A Line: True > .... 0... = Write a SoftKey: False > ...0 .... = Write A Softkey Label: False > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1237526864 (LWP 32058)] > proto_item_fill_label (fi=0x873e200, label_str=0xbfe6e4fc "...0 .... = > Write A Softkey Label: False") at proto.c:3865 > 3865 switch(hfinfo->type) { > > Which, on closer examination shows that hfinfo is 0x8 as well. Why does > finfo->hfinfo gets set to 0x8?? That's the question. > > Thanx, > Jaap > > _______________________________________________ > Wireshark-dev mailing list > Wireshark-dev@xxxxxxxxxxxxx > http://www.wireshark.org/mailman/listinfo/wireshark-dev > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan
- Follow-Ups:
- Re: [Wireshark-dev] Finding the bug in the unistim dissector
- From: Jaap Keuter
- Re: [Wireshark-dev] Finding the bug in the unistim dissector
- References:
- [Wireshark-dev] Finding the bug in the unistim dissector
- From: Jaap Keuter
- [Wireshark-dev] Finding the bug in the unistim dissector
- Prev by Date: [Wireshark-dev] review_for_checkin requested: [Bug 1741] Privilege separation patch
- Next by Date: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 1741] Privilege separation patch
- Previous by thread: [Wireshark-dev] Finding the bug in the unistim dissector
- Next by thread: Re: [Wireshark-dev] Finding the bug in the unistim dissector
- Index(es):