Wireshark · Wireshark-dev: Re: [Wireshark-dev] Finding the bug in the unistim dissector

["Luis EG Ontanon" <luis.ontanon@xxxxxxxxx>]

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