[Bug] Double-free in tcpreplay's tcprewrite utility

[msxfXF]

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 double-free vulnerability exists within the tcprewrite utility of the tcpreplay suite. When handling specific packet capture files, tcprewrite may attempt to free the same memory location twice leading to potential code execution, denial of service, or memory corruption scenarios.

The issue occurs in the tcpedit_dlt_cleanup function, as part of the dlt_plugins.c code, and can be triggered under certain conditions, as evidenced by the provided crash file and stack trace pointing to a problem when cleaning up resources.

To Reproduce
Steps to reproduce the behavior:

1. export CC=clang && export CFLAGS="-fsanitize=address -g"
2. ./autogen.sh && ./configure --disable-shared --disable-local-libopts && make clean && make -j8
3. tcprewrite -o /dev/null -i POC.pcap

Screenshots

Warning: ./id:000000,sig:06,sync:master_write,src:000138 was captured using a snaplen of 9999 bytes.  This may mean you have truncated packets.
=================================================================
==1515869==ERROR: AddressSanitizer: attempting double-free on 0x503000000280 in thread T0:
    #0 0x55ddaa37b476 in free (/usr/local/bin/tcprewrite+0xdf476)
    #1 0x55ddaa3d0b51 in tcpedit_dlt_cleanup /home/shf/固件代码/tcpreplay/src/tcpedit/plugins/dlt_plugins.c:466:9
    #2 0x55ddaa3be500 in tcpedit_close /home/shf/固件代码/tcpreplay/src/tcpedit/tcpedit.c:555:9
    #3 0x55ddaa3ba07c in main /home/shf/固件代码/tcpreplay/src/tcprewrite.c:146:5
    #4 0x7f395fe22082 in __libc_start_main /build/glibc-wuryBv/glibc-2.31/csu/../csu/libc-start.c:308:16
    #5 0x55ddaa2e065d in _start (/usr/local/bin/tcprewrite+0x4465d)

0x503000000280 is located 0 bytes inside of 20-byte region [0x503000000280,0x503000000294)
freed by thread T0 here:
    #0 0x55ddaa37b476 in free (/usr/local/bin/tcprewrite+0xdf476)
    #1 0x55ddaa3d0b51 in tcpedit_dlt_cleanup /home/shf/固件代码/tcpreplay/src/tcpedit/plugins/dlt_plugins.c:466:9

previously allocated by thread T0 here:
    #0 0x55ddaa37b71e in malloc (/usr/local/bin/tcprewrite+0xdf71e)
    #1 0x55ddaa3f33f6 in our_safe_malloc /home/shf/固件代码/tcpreplay/src/common/utils.c:42:16

SUMMARY: AddressSanitizer: double-free (/usr/local/bin/tcprewrite+0xdf476) in free
==1515869==ABORTING

System (please complete the following information):

• OS: Ubuntu
• OS 20.04.1
• Tcpreplay Version 4.4.4

[msxfXF]

POC.pcap

┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ d4 c3 b2 a1 02 00 04 00 ┊ 00 00 00 00 00 00 00 00 │×××ו0•0┊00000000│
│00000010│ 0f 27 00 00 b2 00 00 00 ┊ 57 97 cf 53 c9 00 0c 00 │•'00×000┊W××S×0_0│
│00000020│ da 00 00 00 da 00 00 00 ┊ 4d 47 43 80 00 10 03 01 │×000×000┊MGC×0•••│
│00000030│ 01 06 01 0e 01 02 8c 00 ┊ 04 04 4c 01 00 00 00 50 │••••••×0┊••L•000P│
│00000040│ 56 8b 5e 9f 00 50 56 8b ┊ 6d de 08 00 45 c0 00 b6 │V×^×0PV×┊mו0E×0×│
│00000050│ 88 f7 00 00 40 06 70 62 ┊ ac 10 14 05 ac 10 14 03 │××00@•pb┊ו••×•••│
│00000060│ e8 ef 00 b3 e9 e0 2e 03 ┊ c7 2f 6b 7d 80 18 40 00 │××0×××.•┊×/k}ו@0│
│00000070│ e1 12 00 00 01 01 08 0a ┊ 01 f3 7b 46 01 f2 e5 77 │ו00•••_┊•×{F•××w│
│00000080│ ff ff ff ff ff ff ff ff ┊ ff ff ff ff ff ff ff ff │××××××××┊××××××××│
│00000090│ 00 64 02 00 00 00 4d 40 ┊ 01 01 02 40 02 00 80 04 │0d•000M@┊•••@•0ו│
│000000a0│ 04 00 00 00 00 40 05 04 ┊ 00 00 00 64 c0 08 04 fd │•0000@••┊000dו•×│
│000000b0│ e8 2b c1 80 09 04 ac 10 ┊ 15 04 80 0a 04 ac 10 14 │×+××_•×•┊••×_•×••│
│000000c0│ 05 80 1a 0b 01 00 0b 00 ┊ 00 00 00 00 00 07 d0 90 │•×•••0•0┊00000•××│
│000000d0│ 0e 00 11 00 01 04 04 ac ┊ 10 14 05 00 38 49 44 01 │•0•0•••×┊•••08ID•│
│000000e0│ ac 10 15 04 ff ff ff ff ┊ ff ff ff ff ff ff ff ff │ו••××××┊××××××××│
│000000f0│ ff ff ff ff 00 1e 02 00 ┊ 00 00 07 90 0f 00 03 00 │××××0••0┊00•×•0•0│
│00000100│ 01 04                   ┊                         │••      ┊        │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘

[GabrielGanne]

Looks like this is the same issue as in #813

[fklassen]

Closing as duplicate of #813