12242 – Wireshark heap-based out-of-bounds read in dissect_pktc_rekey

Bug 12242 - Wireshark heap-based out-of-bounds read in dissect_pktc_rekey

Summary: Wireshark heap-based out-of-bounds read in dissect_pktc_rekey

Status:	RESOLVED FIXED

Alias:	None

Product:	Wireshark
Classification:	Unclassified
Component:	Dissection engine (libwireshark) (show other bugs)
Version:	Git
Hardware:	All All

Importance:	Low Major (vote)
Target Milestone:	---
Assignee:	Bugzilla Administrator

URL:

Duplicates (1):	12152 (view as bug list)
Depends on:
Blocks:

Reported:	2016-03-07 12:29 UTC by Mateusz Jurczyk
Modified:	2016-09-21 20:40 UTC (History)
CC List:	2 users (show)

See Also:	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4080

Attachments
Reproducer. (30 bytes, application/octet-stream) 2016-03-07 12:29 UTC, Mateusz Jurczyk	Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Mateusz Jurczyk 2016-03-07 12:29:07 UTC

Created attachment 14406 [details]
Reproducer.

Build Information:
Wireshark git master.
--
The following crash due to a heap-based out-of-bounds read can be observed in an ASAN build of Wireshark (current git master), by feeding a malformed file to tshark ("$ ./tshark -nVxr /path/to/file"):

Attached is a file which triggers the crash.

--- cut ---
==17304==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00001335c at pc 0x0000004507c1 bp 0x7fff09b13420 sp 0x7fff09b12bd0
READ of size 1431 at 0x61b00001335c thread T0
    #0 0x4507c0 in __interceptor_strlen llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:581
    #1 0x7fead8aeeb02 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x65b02)
    #2 0x7feae0a0b1ef in string_fvalue_set_string wireshark/epan/ftypes/ftype-string.c:51:30
    #3 0x7feae09e83f8 in fvalue_set_string wireshark/epan/ftypes/ftypes.c:530:2
    #4 0x7feae0867874 in proto_tree_set_string wireshark/epan/proto.c:3572:3
    #5 0x7feae088ae05 in proto_tree_add_string wireshark/epan/proto.c:3478:2
    #6 0x7feae088b135 in proto_tree_add_string_format_value wireshark/epan/proto.c:3492:7
    #7 0x7feae213aa61 in dissect_pktc_rekey wireshark/epan/dissectors/packet-pktc.c:436:5
    #8 0x7feae2139f71 in dissect_pktc wireshark/epan/dissectors/packet-pktc.c:624:16
    #9 0x7feae08130d1 in call_dissector_through_handle wireshark/epan/packet.c:626:8
    #10 0x7feae0805a4a in call_dissector_work wireshark/epan/packet.c:701:9
    #11 0x7feae080521d in dissector_try_uint_new wireshark/epan/packet.c:1160:9
    #12 0x7feae0805dc4 in dissector_try_uint wireshark/epan/packet.c:1186:9
    #13 0x7feae296ebf5 in decode_udp_ports wireshark/epan/dissectors/packet-udp.c:583:7
    #14 0x7feae297dc90 in dissect wireshark/epan/dissectors/packet-udp.c:1081:5
    #15 0x7feae29719d0 in dissect_udp wireshark/epan/dissectors/packet-udp.c:1087:3
    #16 0x7feae08130d1 in call_dissector_through_handle wireshark/epan/packet.c:626:8
    #17 0x7feae0805a4a in call_dissector_work wireshark/epan/packet.c:701:9
    #18 0x7feae080521d in dissector_try_uint_new wireshark/epan/packet.c:1160:9
    #19 0x7feae19601db in ip_try_dissect wireshark/epan/dissectors/packet-ip.c:1978:7
    #20 0x7feae19cf7c1 in dissect_ipv6 wireshark/epan/dissectors/packet-ipv6.c:2431:14
    #21 0x7feae08130d1 in call_dissector_through_handle wireshark/epan/packet.c:626:8
    #22 0x7feae0805a4a in call_dissector_work wireshark/epan/packet.c:701:9
    #23 0x7feae080521d in dissector_try_uint_new wireshark/epan/packet.c:1160:9
    #24 0x7feae0805dc4 in dissector_try_uint wireshark/epan/packet.c:1186:9
    #25 0x7feae1fde9c9 in dissect_null wireshark/epan/dissectors/packet-null.c:458:12
    #26 0x7feae08130d1 in call_dissector_through_handle wireshark/epan/packet.c:626:8
    #27 0x7feae0805a4a in call_dissector_work wireshark/epan/packet.c:701:9
    #28 0x7feae080521d in dissector_try_uint_new wireshark/epan/packet.c:1160:9
    #29 0x7feae1542dd5 in dissect_frame wireshark/epan/dissectors/packet-frame.c:493:11
    #30 0x7feae08130d1 in call_dissector_through_handle wireshark/epan/packet.c:626:8
    #31 0x7feae0805a4a in call_dissector_work wireshark/epan/packet.c:701:9
    #32 0x7feae080f58e in call_dissector_only wireshark/epan/packet.c:2674:8
    #33 0x7feae0800f4f in call_dissector_with_data wireshark/epan/packet.c:2687:8
    #34 0x7feae0800324 in dissect_record wireshark/epan/packet.c:509:3
    #35 0x7feae07b36c9 in epan_dissect_run_with_taps wireshark/epan/epan.c:376:2
    #36 0x52f11b in process_packet wireshark/tshark.c:3748:5
    #37 0x52840c in load_cap_file wireshark/tshark.c:3504:11
    #38 0x51e71c in main wireshark/tshark.c:2213:13

0x61b00001335c is located 0 bytes to the right of 1500-byte region [0x61b000012d80,0x61b00001335c)
allocated by thread T0 here:
    #0 0x4c2148 in malloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40
    #1 0x7fead8ad7610 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e610)
    #2 0x7feaed2fef08 in wtap_open_offline wireshark/wiretap/file_access.c:1082:2
    #3 0x52473d in cf_open wireshark/tshark.c:4215:9
    #4 0x51e12d in main wireshark/tshark.c:2204:9

SUMMARY: AddressSanitizer: heap-buffer-overflow llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:581 in __interceptor_strlen
Shadow bytes around the buggy address:
  0x0c367fffa610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c367fffa660: 00 00 00 00 00 00 00 00 00 00 00[04]fa fa fa fa
  0x0c367fffa670: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fffa680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fffa690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa6a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa6b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==17304==ABORTING
--- cut ---

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.

Comment 1 Michael Mann 2016-03-10 01:57:17 UTC

Are you sure this is the right attachment?  I can't even get close to this callstack.  This is being dissected as Bluetooth, not IP -> UDP -> PKTC

Comment 2 Mateusz Jurczyk 2016-03-22 18:45:23 UTC

Hmm yes, I am pretty sure. We're talking about a 30-byte file of md5sum dc39676e9920dc3f066bb8e7441c0348, and it gets dissected as IP -> UDP -> PKTC in both my Windows Wireshark installation and a tshark build of git trunk. The reported crash still reproduces.

Comment 3 Jaap Keuter 2016-03-27 10:59:34 UTC

A proper report of the build information (as asked when filing the bug) would be appreciated, since development is moving and the referenced files have already been changed, making the line numbers unreliable and reproducing the exact same conditions problematic.
Currently (445a57bdc35f5f09ef878b6bf5a46d7018ddddcc) crash not yet reproduced, although timestamp presentation is problematic.

Comment 4 Mateusz Jurczyk 2016-03-29 15:02:12 UTC

Build information:

--- cut ---
TShark (Wireshark) 2.1.0 (v2.1.0rc0-2515-g130ecc3 from master)

Compiled (64-bit) with libpcap, without POSIX capabilities, without libnl, with
libz 1.2.8, with GLib 2.40.2, without SMI, without c-ares, without Lua, without
GnuTLS, without Gcrypt, with MIT Kerberos, without GeoIP.

Running on Linux 3.13.0-77-generic, with locale en_US.UTF-8, with libpcap
version 1.5.3, with libz 1.2.8.
      Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz (with SSE4.2)

Built using clang 4.2.1 Compatible Clang 3.8.0 (trunk 251411).
--- cut ---

Current ASAN report is as follows:

--- cut ---
=================================================================
==22630==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00001335c at pc 0x0000004507c1 bp 0x7ffcdb3fa4c0 sp 0x7ffcdb3f9c70
READ of size 1431 at 0x61b00001335c thread T0
    #0 0x4507c0 in __interceptor_strlen llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:581
    #1 0x7f3879b20b02 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x65b02)
    #2 0x7f3881a678df in string_fvalue_set_string wireshark/epan/ftypes/ftype-string.c:51:30
    #3 0x7f3881a44b78 in fvalue_set_string wireshark/epan/ftypes/ftypes.c:530:2
    #4 0x7f38818c3df4 in proto_tree_set_string wireshark/epan/proto.c:3572:3
    #5 0x7f38818e7385 in proto_tree_add_string wireshark/epan/proto.c:3478:2
    #6 0x7f38818e76b5 in proto_tree_add_string_format_value wireshark/epan/proto.c:3492:7
    #7 0x7f38831ddf71 in dissect_pktc_rekey wireshark/epan/dissectors/packet-pktc.c:439:5
    #8 0x7f38831dcf01 in dissect_pktc wireshark/epan/dissectors/packet-pktc.c:641:16
    #9 0x7f388186f5b1 in call_dissector_through_handle wireshark/epan/packet.c:654:8
    #10 0x7f388186130a in call_dissector_work wireshark/epan/packet.c:729:9
    #11 0x7f3881860add in dissector_try_uint_new wireshark/epan/packet.c:1188:9
    #12 0x7f3881861684 in dissector_try_uint wireshark/epan/packet.c:1214:9
    #13 0x7f3883a219e5 in decode_udp_ports wireshark/epan/dissectors/packet-udp.c:582:7
    #14 0x7f3883a30a80 in dissect wireshark/epan/dissectors/packet-udp.c:1080:5
    #15 0x7f3883a247d0 in dissect_udp wireshark/epan/dissectors/packet-udp.c:1086:3
    #16 0x7f388186f5b1 in call_dissector_through_handle wireshark/epan/packet.c:654:8
    #17 0x7f388186130a in call_dissector_work wireshark/epan/packet.c:729:9
    #18 0x7f3881860add in dissector_try_uint_new wireshark/epan/packet.c:1188:9
    #19 0x7f38829e9f8b in ip_try_dissect wireshark/epan/dissectors/packet-ip.c:1977:7
    #20 0x7f3882a5958a in dissect_ipv6 wireshark/epan/dissectors/packet-ipv6.c:2429:14
    #21 0x7f388186f5b1 in call_dissector_through_handle wireshark/epan/packet.c:654:8
    #22 0x7f388186130a in call_dissector_work wireshark/epan/packet.c:729:9
    #23 0x7f3881860add in dissector_try_uint_new wireshark/epan/packet.c:1188:9
    #24 0x7f3881861684 in dissector_try_uint wireshark/epan/packet.c:1214:9
    #25 0x7f388307f882 in dissect_null wireshark/epan/dissectors/packet-null.c:457:12
    #26 0x7f388186f5b1 in call_dissector_through_handle wireshark/epan/packet.c:654:8
    #27 0x7f388186130a in call_dissector_work wireshark/epan/packet.c:729:9
    #28 0x7f3881860add in dissector_try_uint_new wireshark/epan/packet.c:1188:9
    #29 0x7f38825c8575 in dissect_frame wireshark/epan/dissectors/packet-frame.c:492:11
    #30 0x7f388186f5b1 in call_dissector_through_handle wireshark/epan/packet.c:654:8
    #31 0x7f388186130a in call_dissector_work wireshark/epan/packet.c:729:9
    #32 0x7f388186b6ce in call_dissector_only wireshark/epan/packet.c:2730:8
    #33 0x7f388185c6bf in call_dissector_with_data wireshark/epan/packet.c:2743:8
    #34 0x7f388185ba94 in dissect_record wireshark/epan/packet.c:537:3
    #35 0x7f388180eb09 in epan_dissect_run_with_taps wireshark/epan/epan.c:376:2
    #36 0x52f11b in process_packet wireshark/tshark.c:3751:5
    #37 0x52840c in load_cap_file wireshark/tshark.c:3507:11
    #38 0x51e71c in main wireshark/tshark.c:2216:13

0x61b00001335c is located 0 bytes to the right of 1500-byte region [0x61b000012d80,0x61b00001335c)
allocated by thread T0 here:
    #0 0x4c2148 in malloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40
    #1 0x7f3879b09610 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e610)
    #2 0x7f388e3e1f28 in wtap_open_offline wireshark/wiretap/file_access.c:1083:2
    #3 0x52473d in cf_open wireshark/tshark.c:4218:9
    #4 0x51e12d in main wireshark/tshark.c:2207:9

SUMMARY: AddressSanitizer: heap-buffer-overflow llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:581 in __interceptor_strlen
Shadow bytes around the buggy address:
  0x0c367fffa610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c367fffa660: 00 00 00 00 00 00 00 00 00 00 00[04]fa fa fa fa
  0x0c367fffa670: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fffa680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fffa690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa6a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa6b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==22630==ABORTING
--- cut ---

Please let me know if there is anything else I can do to help pin down the issue.

Comment 5 Jaap Keuter 2016-03-31 11:32:20 UTC

Change 14714 had a related patch set uploaded by Jaap Keuter:
replace dangerous tvb_get_ptr with safer string function.

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

Comment 6 Jaap Keuter 2016-03-31 11:38:37 UTC

Change 14714 merged by Alexis La Goutte:
Dynamically allocate info string to prevent stack overflow.

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

Comment 7 Jaap Keuter 2016-03-31 11:40:02 UTC

Please retest.
If to found to be in order backport to be considered.

Comment 8 Mateusz Jurczyk 2016-03-31 14:17:05 UTC

I confirm that the crash no longer reproduces.

Comment 9 Gerald Combs 2016-04-19 21:14:04 UTC

Making public. Fixes have been in Git for a while and affected releases should be out soon.

Comment 10 Gerrit Code Review 2016-05-15 19:47:52 UTC

Change 15443 had a related patch set uploaded by Balint Reczey:
replace dangerous tvb_get_ptr with safer string function.

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

Comment 11 Gerrit Code Review 2016-05-17 19:43:00 UTC

Change 15443 merged by Balint Reczey:
replace dangerous tvb_get_ptr with safer string function.

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

Comment 12 Pascal Quantin 2016-09-21 20:40:44 UTC

*** Bug 12152 has been marked as a duplicate of this bug. ***