Wireshark stack-based buffer overflow in AirPDcapPacketProcess
Created attachment 14045 [details] Reproducers. Build Information: Wireshark git master. -- The following crash due to a stack-based buffer overflow 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 are three files which trigger the crash. --- cut --- ==2992==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe9b2a2fc0 at pc 0x0000004c1386 bp 0x7ffe9b2a0f70 sp 0x7ffe9b2a0720 WRITE of size 43264 at 0x7ffe9b2a2fc0 thread T0 #0 0x4c1385 in __asan_memcpy llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:393 #1 0x4189c2b in AirPDcapPacketProcess wireshark/epan/crypt/airpdcap.c:713:9 #2 0x29525e9 in dissect_ieee80211_common wireshark/epan/dissectors/packet-ieee80211.c:17767:9 #3 0x2924581 in dissect_ieee80211 wireshark/epan/dissectors/packet-ieee80211.c:18375:10 #4 0xaf3794 in call_dissector_through_handle wireshark/epan/packet.c:616:8 #5 0xae5692 in call_dissector_work wireshark/epan/packet.c:691:9 #6 0xaefb1b in call_dissector_only wireshark/epan/packet.c:2662:8 #7 0xae09f3 in call_dissector_with_data wireshark/epan/packet.c:2675:8 #8 0x28d825c in dissect_wlan_radio wireshark/epan/dissectors/packet-ieee80211-radio.c:976:10 #9 0xaf3794 in call_dissector_through_handle wireshark/epan/packet.c:616:8 #10 0xae5692 in call_dissector_work wireshark/epan/packet.c:691:9 #11 0xaefb1b in call_dissector_only wireshark/epan/packet.c:2662:8 #12 0xae09f3 in call_dissector_with_data wireshark/epan/packet.c:2675:8 #13 0x28e5df4 in dissect_radiotap wireshark/epan/dissectors/packet-ieee80211-radiotap.c:1796:2 #14 0xaf3794 in call_dissector_through_handle wireshark/epan/packet.c:616:8 #15 0xae5692 in call_dissector_work wireshark/epan/packet.c:691:9 #16 0xae4e1d in dissector_try_uint_new wireshark/epan/packet.c:1148:9 #17 0x25dca12 in dissect_frame wireshark/epan/dissectors/packet-frame.c:500:11 #18 0xaf3794 in call_dissector_through_handle wireshark/epan/packet.c:616:8 #19 0xae5692 in call_dissector_work wireshark/epan/packet.c:691:9 #20 0xaefb1b in call_dissector_only wireshark/epan/packet.c:2662:8 #21 0xae09f3 in call_dissector_with_data wireshark/epan/packet.c:2675:8 #22 0xadffde in dissect_record wireshark/epan/packet.c:501:3 #23 0xab6d0d in epan_dissect_run_with_taps wireshark/epan/epan.c:373:2 #24 0x53c91b in process_packet wireshark/tshark.c:3728:5 #25 0x535d90 in load_cap_file wireshark/tshark.c:3484:11 #26 0x52c1df in main wireshark/tshark.c:2197:13 Address 0x7ffe9b2a2fc0 is located in stack of thread T0 at offset 8256 in frame #0 0x418907f in AirPDcapPacketProcess wireshark/epan/crypt/airpdcap.c:630 This frame has 5 object(s): [32, 44) 'id' [64, 8256) 'tmp_data' [8512, 8516) 'tmp_len' <== Memory access at offset 8256 partially underflows this variable [8528, 8544) 'id.coerce' <== Memory access at offset 8256 partially underflows this variable [8560, 8576) 'id.coerce83' <== Memory access at offset 8256 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:393 in __asan_memcpy Shadow bytes around the buggy address: 0x10005364c5a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10005364c5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10005364c5c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10005364c5d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10005364c5e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10005364c5f0: 00 00 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 0x10005364c600: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 0x10005364c610: f2 f2 f2 f2 f2 f2 f2 f2 04 f2 00 00 f2 f2 00 00 0x10005364c620: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x10005364c630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10005364c640: 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 ==2992==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.
This bug is also already marked as public... There is a "private" option when reporting the bug.
Whoops, fail. Thanks for pointing this out, any chance to change the visibility post-factum?
The information is already out in the public, so changing the visibility won't change that. We will investigate the bug. (patches are welcome though if you have them) Thanks for the reports btw!
Can confirm that this is a real issue. Affects at least Wireshark master and 2.0.0. 1.12.8 somehow did not crash on the capture. Workaround: disable 802.11 decryption: tshark -r 1.pcap -o wlan.enable_decryption:0 -- ASAN backtrace for v2.0.0-69-g6793a03 is slightly different, possibly because master has v2.1.0rc0-460-gcb3dd95: ==23836==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffff1ed0 at pc 0x555555698f45 bp 0x7ffffffefaf0 sp 0x7ffffffef2a0 WRITE of size 43264 at 0x7fffffff1ed0 thread T0 #0 0x555555698f44 in __asan_memcpy (/tmp/wireshark-1.12/build-2.0/run/tshark+0x144f44) #1 0x7fffea9dbb5e in AirPDcapPacketProcess epan/crypt/airpdcap.c:708:13 #2 0x7fffebace4a0 in try_decrypt epan/dissectors/packet-ieee80211.c:18744:7 #3 0x7fffebac6e52 in dissect_ieee80211_common epan/dissectors/packet-ieee80211.c:17857:16 #4 0x7fffeba94fe5 in dissect_ieee80211 epan/dissectors/packet-ieee80211.c:18358:10 As far as I can see, the bug reaches far back. Maybe there is a way to trigger the issue in other versions, but I did not check.
Change 12237 had a related patch set uploaded by Peter Wu: Add boundary check for 802.11 decryption https://code.wireshark.org/review/12237
Change 12237 merged by Peter Wu: Add boundary check for 802.11 decryption https://code.wireshark.org/review/12237
Change 12246 had a related patch set uploaded by Peter Wu: Add boundary check for 802.11 decryption https://code.wireshark.org/review/12246
Change 12246 merged by Peter Wu: Add boundary check for 802.11 decryption https://code.wireshark.org/review/12246
Change 12247 had a related patch set uploaded by Peter Wu: Add boundary check for 802.11 decryption https://code.wireshark.org/review/12247
Change 12247 merged by Peter Wu: Add boundary check for 802.11 decryption https://code.wireshark.org/review/12247
Change 13761 had a related patch set uploaded by Balint Reczey: Add boundary check for 802.11 decryption https://code.wireshark.org/review/13761
Change 13761 merged by Balint Reczey: Add boundary check for 802.11 decryption https://code.wireshark.org/review/13761
Change 14375 had a related patch set uploaded by Balint Reczey: Add boundary check for 802.11 decryption https://code.wireshark.org/review/14375
Change 14375 merged by Balint Reczey: Add boundary check for 802.11 decryption https://code.wireshark.org/review/14375