Wireshark · Ethereal-dev: [Ethereal-dev] SEGV in ethereal/tethereal

[Pierre-Yves Bonnetain <bonnetain@xxxxxxx>]

   Hi everybody there,

   I've been using ethereal for some time now, and today ran into a
SEGV. It
seems some NULL pointer gets dereferenced somewhere.
   Linux 2.4.5, ethereal 0.8.20, gtk 1.2.6. Sniffing on a M$-heavy
network.
   Here is the backtrace :

(gdb) run
Starting program: /tmp/ethereal-0.8.20/tethereal -r ../titi
Program received signal SIGSEGV, Segmentation fault.

(gdb) backtrace
#0  0x0 in ?? ()
#1  0x8141a24 in dissect_pipe_lanman (tvb=0x836e12c, pinfo=0x82cffa0, 
    parent_tree=0x0) at packet-smb-pipe.c:2129
#2  0x8141b93 in dissect_pipe_smb (tvb=0x836e12c, pinfo=0x82cffa0,
tree=0x0)
    at packet-smb-pipe.c:2198
#3  0x813b122 in dissect_transact_params (pd=0x836cdd0 "", offset=114, 
    fd=0xbffff8c8, parent=0x0, tree=0x0, si={tid = 2059, uid = 10240, 
      mid = 42881, pid = 3399, conversation = 0x83712c0, 
      request_val = 0x8372ad0, continuation_val = 0x0, unicode = 1, 
      request = 0, is_interim_response = 0, parameter_count = 8, 
      data_offset = 8, data_count = 126, ddisp = 0, 
      trans_cmd = 0x83760f6 "LANMAN"}, max_data=190, SMB_offset=58, 
    DataOffset=64, DataCount=126, ParameterOffset=56,
ParameterCount=8, 
    SetupAreaOffset=111, SetupCount=0, TransactName=0x8374ac0
"\\PIPE\\LANMAN")
    at packet-smb.c:10420
#4  0x813c413 in dissect_transact_smb (pd=0x836cdd0 "", offset=114, 
    fd=0xbffff8c8, parent=0x0, tree=0x0, si={tid = 2059, uid = 10240, 
      mid = 42881, pid = 3399, conversation = 0x83712c0, 
      request_val = 0x8372ad0, continuation_val = 0x0, unicode = 1, 
      request = 0, is_interim_response = 135897550, 
      parameter_count = 137199768, data_offset = -1073746868, 
      data_count = 135897476, ddisp = 0, trans_cmd = 0xbfffec54
"øà6\b ÿ,\b"}, 
    max_data=190, SMB_offset=58) at packet-smb.c:11124
---Type <return> to continue, or q <return> to quit---
#5  0x813ce64 in dissect_smb (tvb=0x836e0f8, pinfo=0x82cffa0,
tree=0x0)
    at packet-smb.c:12610
#6  0x81977ca in dissector_try_heuristic (sub_dissectors=0x82d0738, 
    tvb=0x836e0f8, pinfo=0x82cffa0, tree=0x0) at packet.c:708
#7  0x80eb0ee in dissect_netbios_payload (tvb=0x836e0f8,
pinfo=0x82cffa0, 
    tree=0x0) at packet-netbios.c:965
#8  0x80e8908 in dissect_nbss_packet (tvb=0x836e0c4, offset=4, 
    pinfo=0x82cffa0, tree=0x0, max_data=194, is_cifs=0) at
packet-nbns.c:1497
#9  0x80e8b85 in dissect_nbss (tvb=0x836e0c4, pinfo=0x82cffa0,
tree=0x0)
    at packet-nbns.c:1672
#10 0x81971c3 in dissector_try_port (sub_dissectors=0x830d838,
port=139, 
    tvb=0x836e0c4, pinfo=0x82cffa0, tree=0x0) at packet.c:459
#11 0x814f3dd in decode_tcp_ports (tvb=0x836e090, offset=20,
pinfo=0x82cffa0, 
    tree=0x0, src_port=139, dst_port=1025) at packet-tcp.c:800
#12 0x81500ef in dissect_tcp (tvb=0x836e090, pinfo=0x82cffa0,
tree=0x0)
    at packet-tcp.c:1101
#13 0x81971c3 in dissector_try_port (sub_dissectors=0x82d3ca8, port=6, 
    tvb=0x836e090, pinfo=0x82cffa0, tree=0x0) at packet.c:459
#14 0x80b940c in dissect_ip (tvb=0x836e05c, pinfo=0x82cffa0, tree=0x0)
    at packet-ip.c:1109
#15 0x81971c3 in dissector_try_port (sub_dissectors=0x82d48c8,
port=2048, 
    tvb=0x836e05c, pinfo=0x82cffa0, tree=0x0) at packet.c:459
#16 0x8094bcb in ethertype (etype=2048, tvb=0x836e028,
offset_after_etype=14, 
---Type <return> to continue, or q <return> to quit---
    pinfo=0x82cffa0, tree=0x0, fh_tree=0x0, etype_id=630,
trailer_id=632)
    at packet-ethertype.c:154
#17 0x8094952 in dissect_eth (tvb=0x836e028, pinfo=0x82cffa0,
tree=0x0)
    at packet-eth.c:256
#18 0x81971c3 in dissector_try_port (sub_dissectors=0x82d5178, port=1, 
    tvb=0x836e028, pinfo=0x82cffa0, tree=0x0) at packet.c:459
#19 0x8096292 in dissect_frame (tvb=0x836e028, pinfo=0x82cffa0,
tree=0x0)
    at packet-frame.c:123
#20 0x8197d9b in call_dissector (handle=0x82d51f0, tvb=0x836e028, 
    pinfo=0x82cffa0, tree=0x0) at packet.c:909
#21 0x8196d27 in dissect_packet (p_tvb=0x836e000,
pseudo_header=0x835df4c, 
    pd=0x836cdd0 "", fd=0xbffff8c8, tree=0x0) at packet.c:210
#22 0x8195b6b in epan_dissect_new (pseudo_header=0x835df4c,
data=0x836cdd0 "", 
    fd=0xbffff8c8, tree=0x0) at epan.c:91
#23 0x8183e90 in wtap_dispatch_cb_print (user=0xbffff958 "@þ+\b", 
    phdr=0x835df38, offset=229, pseudo_header=0x835df4c, buf=0x836cdd0
"")
    at tethereal.c:1175
#24 0x818fbcf in wtap_loop (wth=0x835df20, count=0, 
    callback=0x8183e0c <wtap_dispatch_cb_print>, user=0xbffff958
"@þ+\b", 
    err=0xbffff964) at wtap.c:283
#25 0x8183819 in load_cap_file (cf=0x82bfe40, out_file_type=2)
    at tethereal.c:927
#26 0x8182fc1 in main (argc=3, argv=0xbffffb14) at tethereal.c:585

   To get things a little clearer :

(gdb) up
#1  0x8141a24 in dissect_pipe_lanman (tvb=0x836e12c, pinfo=0x82cffa0, 
    parent_tree=0x0) at packet-smb-pipe.c:2129
(gdb) list
2124                                    if (has_ent_count) {
2125                                            /*
2126                                             * Create a protocol
tree item for the
2127                                             * entry.
2128                                             */
2129                                            entry_item =
2130                                               
(*lanman->resp_data_element_item)
2131                                                  (tvb, pinfo,
data_tree, offset);
2132                                            entry_tree =
proto_item_add_subtree(
2133                                                entry_item,
(gdb) print *lanman
$1 = {lanman_num = -1, req = 0x823477c, req_data_item = 0,
ett_req_data = 0x0, 
  req_data = 0x823477c, req_aux_data = 0x823477c, resp = 0x823477c, 
  resp_data_item = 0, ett_resp_data = 0x0, resp_data_element_item = 0, 
  ett_resp_data_element_item = 0x0, resp_data_list = 0x8234788, 
  resp_aux_data = 0x823477c}

   It's obvious that using *lanman->resp_data_element_item will send
us in no-no land :-)

   The data file is HUGE, but I extracted the minimum to crash
properly
ethereal (that's two packets). It should be attached to this message.

   Hope all that helps - and I would be glad (if possible, of course)
to get
a quick patch, in order to analyse my data !
   Thanks !

-- Pierre-Yves Bonnetain
   Consultant Sécurité -- B&A Consultants
   Tél +33 (0) 563 277 241 -- Fax +33 (0) 563 277 245

Ôò¡ÿÿ
õhN<2­­07? $ÄÏÄEYK@ ePÀ¨?³À¨?
<
w	XYáP W?ÙsÿSMB%?G
(?§~^Z4\PIPE\LANMAN;zWrLehB21YY04510~õhN<<8øø $ÄÏÄ07?Eê&¢@?)eÀ¨?À¨?³<
	XYá
w?P NÊ·¾ÿSMB%??G
(?§
~8~@?Utilisa. du domaineBOULOT1GRPUSERSNiveau 0Niveau 1EXCHANGE