[Bug] heap buffer overflow still exists in parse_mpls
0xdd96 opened this issue · 1 comments
You are opening a bug report against the Tcpreplay project: we use
GitHub Issues for tracking bug reports and feature requests.
If you have a question about how to use Tcpreplay, you are at the wrong
site. You can ask a question on the tcpreplay-users mailing list
or on Stack Overflow with [tcpreplay] tag.
General help is available here.
If you have a build issue, consider downloading the latest release
Otherwise, to report a bug, please fill out the reproduction steps
(below) and delete these introductory paragraphs. Thanks!
Describe the bug
A heap-overflow still exists in parse_mpls, can be triggered via tcpprep+ ASan. This is similar to issue #719, but it seems that the patch 1de1a21 has not fully fixed it.
To Reproduce
Steps to reproduce the behavior:
- ./autogen.sh
- CFLAGS="-fsanitize=address -g -O0" ./configure --disable-shared --disable-local-libopts
- make -j
- ./src/tcpprep --auto=bridge --pcap=$POC --cachefile=/dev/null
Expected behavior
user@c3ae4d510abb:$ ./src/tcpprep --auto=bridge --pcap=$POC --cachefile=/dev/null
Warning: $POC was captured using a snaplen of 22 bytes. This may mean you have truncated packets.
=================================================================
==24294==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000026 at pc 0x5555555737f8 bp 0x7fffffffdcd0 sp 0x7fffffffdcc0
READ of size 1 at 0x603000000026 thread T0
#0 0x5555555737f7 in parse_mpls tcpreplay/src/common/get.c:133
#1 0x555555573d1c in parse_metadata tcpreplay/src/common/get.c:223
#2 0x5555555747b6 in get_l2len_protocol tcpreplay/src/common/get.c:332
#3 0x555555575324 in get_ipv4 tcpreplay/src/common/get.c:447
#4 0x555555562635 in process_raw_packets tcpreplay/src/tcpprep.c:368
#5 0x5555555617c0 in main tcpreplay/src/tcpprep.c:144
#6 0x7ffff72a0082 in __libc_start_main ../csu/libc-start.c:308
#7 0x55555555ecad in _start (tcpreplay/src/tcpprep+0xacad)
0x603000000026 is located 0 bytes to the right of 22-byte region [0x603000000010,0x603000000026)
allocated by thread T0 here:
#0 0x7ffff768d808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7ffff7559470 in pcap_check_header sf-pcap.c:401
#2 0x7ffff7558c99 in pcap_fopen_offline_with_tstamp_precision savefile.c:400
#3 0x7ffff7558b43 in pcap_open_offline_with_tstamp_precision savefile.c:307
#4 0x7ffff7558b99 in pcap_open_offline savefile.c:318
#5 0x55555556120a in main tcpreplay/src/tcpprep.c:100
#6 0x7ffff72a0082 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-buffer-overflow tcpreplay/src/common/get.c:133 in parse_mpls
Shadow bytes around the buggy address:
0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c067fff8000: fa fa 00 00[06]fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
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
Shadow gap: cc
==24294==ABORTING
System (please complete the following information):