Dissector bug in JSON protocol

This issue was migrated from bug 10115 in our old bug tracker.

Original bug information:

Reporter: Sloven
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: Windows 7
Platform: x86
Version: 1.10.7

Attachments:

JSON_dessector.pcapng: reproduce JSON dessector error

See also: Issue #10081 (closed)

Sloven said:

Created attachment 12764 reproduce JSON dessector error

Build Information: Version 1.10.7 (v1.10.7-0-g6b931a15 from master-1.10)

Compiled (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities, without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Apr 22 2014), with AirPcap.

Running on 32-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap. Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, with 3070MB of physical memory.

Built using Microsoft Visual C++ 10.0 build 40219

choose "3 МБайт" and press the button

Warn Dissector bug, protocol JSON, in packet 10551: emem.c:784: failed assertion "size<((10 * 1024 * 1024)>>2)"

added libwireshark oswindows version1.10 labels

Alexis La Goutte said:

the backtrace

#0  0x00007ffff0811f77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff08155e8 in __GI_abort () at abort.c:90
#2  0x00007ffff1027fdd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff10453b7 in g_assertion_message () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff104541a in g_assertion_message_expr () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff537f819 in wmem_block_fast_alloc (private_data=<optimized out>, size=3145717) at wmem_allocator_block_fast.c:97
#6  0x00007ffff4c68180 in json_string_unescape (tok=0x7fffbfdda6c0) at packet-json.c:277
#7  after_value (tvbparse_data=<optimized out>, wanted_data=<optimized out>, tok=0x7fffbfdda6c0) at packet-json.c:414
#8  0x00007ffff48b47ca in execute_callbacks (curr=0x7fffbfdda6c0, tt=0x7fffbfdda0a0) at tvbparse.c:1280
#9  0x00007ffff48b518e in tvbparse_get (tt=tt@entry=0x7fffbfdda0a0, wanted=<optimized out>) at tvbparse.c:1341
#10 0x00007ffff4c67dff in dissect_json (tvb=0x1b98800, pinfo=0x7fffffffdac8, tree=0x0, data=<optimized out>) at packet-json.c:158
#11 0x00007ffff4886e4f in call_dissector_through_handle (handle=handle@entry=0x133c4b0, tvb=tvb@entry=0x1b98800, pinfo=pinfo@entry=0x7fffffffdac8,
    tree=tree@entry=0x0, data=data@entry=0x0) at packet.c:592
#12 0x00007ffff4887725 in call_dissector_work (handle=0x133c4b0, tvb=0x1b98800, pinfo_arg=0x7fffffffdac8, tree=0x0, add_proto_name=1, data=0x0) at packet.c:683
#13 0x00007ffff4bd4c29 in dissect_http_message (tvb=tvb@entry=0x1b7e770, offset=<optimized out>, offset@entry=0, pinfo=pinfo@entry=0x7fffffffdac8,
    tree=tree@entry=0x0, conv_data=conv_data@entry=0x7fffbd7d46d0) at packet-http.c:1450
#14 0x00007ffff4bd5d09 in dissect_http (tvb=0x1b7e770, pinfo=0x7fffffffdac8, tree=0x0, data=<optimized out>) at packet-http.c:2777
#15 0x00007ffff4886e4f in call_dissector_through_handle (handle=handle@entry=0x130ec90, tvb=tvb@entry=0x1b7e770, pinfo=pinfo@entry=0x7fffffffdac8,
    tree=tree@entry=0x0, data=data@entry=0x7fffffffca40) at packet.c:592
#16 0x00007ffff4887725 in call_dissector_work (handle=0x130ec90, tvb=0x1b7e770, pinfo_arg=0x7fffffffdac8, tree=0x0, add_proto_name=1, data=0x7fffffffca40)
    at packet.c:683
#17 0x00007ffff487a6e7 in try_conversation_dissector (addr_a=addr_a@entry=0x7fffffffdb58, addr_b=addr_b@entry=0x7fffffffdb70, ptype=ptype@entry=PT_TCP,
    port_a=port_a@entry=80, port_b=port_b@entry=49974, tvb=tvb@entry=0x1b7e770, pinfo=pinfo@entry=0x7fffffffdac8, tree=tree@entry=0x0,
    data=data@entry=0x7fffffffca40) at conversation.c:1307
#18 0x00007ffff4f526ab in decode_tcp_ports (tvb=tvb@entry=0x1b7e590, offset=<optimized out>, pinfo=pinfo@entry=0x7fffffffdac8, tree=tree@entry=0x0,
    src_port=src_port@entry=80, dst_port=dst_port@entry=49974, tcpd=tcpd@entry=0x7fffbd7d4030, tcpinfo=tcpinfo@entry=0x7fffffffca40) at packet-tcp.c:3875
#19 0x00007ffff4f52c4f in process_tcp_payload (tvb=tvb@entry=0x1b7e590, offset=offset@entry=0, pinfo=pinfo@entry=0x7fffffffdac8, tree=tree@entry=0x0,
    tcp_tree=tcp_tree@entry=0x0, src_port=src_port@entry=80, dst_port=dst_port@entry=49974, seq=seq@entry=0, nxtseq=nxtseq@entry=0,
    is_tcp_segment=is_tcp_segment@entry=0, tcpd=tcpd@entry=0x7fffbd7d4030, tcpinfo=tcpinfo@entry=0x7fffffffca40) at packet-tcp.c:3991
#20 0x00007ffff4f53440 in desegment_tcp (tcpinfo=0x7fffffffca40, tcpd=0x7fffbd7d4030, tcp_tree=0x0, tree=0x0, dport=49974, sport=80, nxtseq=3146035, seq=3145057,
    offset=32, pinfo=0x7fffffffdac8, tvb=0x1b7e6d0) at packet-tcp.c:1868
#21 dissect_tcp_payload (tvb=tvb@entry=0x1b7e6d0, pinfo=pinfo@entry=0x7fffffffdac8, offset=offset@entry=32, seq=<optimized out>, nxtseq=nxtseq@entry=3146035,
    sport=80, dport=49974, tree=tree@entry=0x0, tcp_tree=tcp_tree@entry=0x0, tcpd=tcpd@entry=0x7fffbd7d4030, tcpinfo=tcpinfo@entry=0x7fffffffca40)
    at packet-tcp.c:4058
#22 0x00007ffff4f54e37 in dissect_tcp (tvb=<optimized out>, pinfo=0x7fffffffdac8, tree=0x0) at packet-tcp.c:4866

Michael Mann said:

This is very similar to bug #10081 (closed) in that the Content-Length field in HTTP is greater than the maximum size that emem allowed. But this is occuring during actual dissection (where emem is supposed to be used), not just outputing fields.

Is it fair to question whether tvbparse functionality should use emem? It appears that where this issues lies, but again Content-Length is really to blame.

Also of note, in 1.10.7 in Windows I get the "Dissector bug" noted here, but it crashes Wireshark completely on the trunk.

Jakub Zawadzki said:

(In reply to comment #2)  
> Is it fair to question whether tvbparse functionality should use emem?  It  
> appears that where this issues lies, but again Content-Length is really to  
> blame.  

It's not a problem with tvbparse using emem, it's JSON dissector trying to allocate this memory:

275 static char *json_string_unescape(tvbparse_elem_t *tok)
277         char *str = (char *)wmem_alloc(wmem_packet_scope(), tok->len - 1);

// where tok->len == 3145718 (3.1 MB)

Not sure what can be done - I was thinking about just returning not unescaped string, but in such way, filtering might not work (like you need to search for string "xxx", but malware escape it to \u0078\u0078\u0078) - just a sample.

Anyway, allocator should not do abort().

Evan Huus said:

I guess we shouldn't have removed jumbo support from fast block allocator after all, sorry :P

Allocating 3 MB is not terribly unreasonable for a dissector in weird conditions; it seems like a validly calculated length (after a *lot* of reassembly) so we should only fail on it if the OS can't give us any more memory.

https://code.wireshark.org/review/1688

Evan Huus said:

And a potential fix for 1.10: https://code.wireshark.org/review/1710

closed