Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buffer overflow on corrupted pcaps in tcpcapinfo #192

Closed
op7ic opened this issue Jun 30, 2015 · 1 comment
Closed

buffer overflow on corrupted pcaps in tcpcapinfo #192

op7ic opened this issue Jun 30, 2015 · 1 comment

Comments

@op7ic
Copy link

op7ic commented Jun 30, 2015

Hi Guys,

I got this when playing with some corrupted pcaps today:

==31832==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe581f2710 at pc 0x7f053533e9b6 bp 0x7ffe581efe60 sp 0x7ffe581efe48
WRITE of size 10046 at 0x7ffe581f2710 thread T0
#0 0x7f053533e9b5 in read (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x299b5)
#1 0x4031bb in main /root/tcpdump/source/tcpreplay-4.1.0/src/tcpcapinfo.c:301
#2 0x7f0534b6db44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
#3 0x4043de (/root/tcpdump/source/tcpreplay-4.1.0/src/tcpcapinfo+0x4043de)

Address 0x7ffe581f2710 is located in stack of thread T0 at offset 10288 in frame
#0 0x40297f in main /root/tcpdump/source/tcpreplay-4.1.0/src/tcpcapinfo.c:100

This frame has 3 object(s):
[32, 56) 'pcap_ph'
[96, 240) 'statinfo'
[288, 10288) 'buf' <== Memory access at offset 10288 overflows 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 ??:0 read
Shadow bytes around the buggy address:
0x10004b036490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b0364a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b0364b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b0364c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b0364d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10004b0364e0: 00 00[f4]f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
0x10004b0364f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b036500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b036510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b036520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10004b036530: 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
Contiguous container OOB:fc
ASan internal: fe

Poc can be reproduced like this:

/tcpdump/source/tcpreplay-4.1.0/src/tcpcapinfo PoC.pcap

a PoC file is attached (its pcap with extension .png because github doesn't let you upload pcap)
poc pcap
.

Cheers,
op7ic

@fklassen
Copy link
Member

Hi, apologies for the delay. Best to post to Main forum for tcpreplay tcpreplay-users@lists.sourceforge.net where there are more eyes watching.

From your stack trace, it appears the issue is identified by libasan, which I believe is Fedora address protection code. I believe it is interfering, and not allowing processing to proceed, namely because the file is corrupt. As you can see, it tries to allocate 540422189 bytes for the next packet, then aborts.

I'll keep this open as a bug for now, but it is very low priority. I may put some protections in place to handle corrupt files.

$ src/tcpcapinfo ~/Downloads/poc.pcap 
file size   = 32105 bytes
magic       = 0xa1b2c3d4 (tcpdump) (little-endian)
version     = 2.4
thiszone    = 0x00000000
sigfigs     = 0x00000000
snaplen     = 65535
linktype    = 0x00000001
Packet  OrigLen     Caplen      Timestamp   Csum    Note
1     74          74        4d2b0707.e0f    d7a92   OK
2     74          74        4d2b0707.e2a    e7a91   OK
3     66          66        4d2b0707.e8a    d8292   OK
4    100         100        4d2b0707.f78    12608d  OK
5     66          66        4d2b0707.f87    c8293   OK
6     79          79        4d2b0707.118b   e7591   OK
7     66          66        4d2b0707.11e8   d8292   OK
8    107         107        4d2b0707.120c   11598e  OK
9    369         369        4d2b0707.1a71   395365  OK
10    66          66        4d2b0707.9f27   d8292   OK
11    98          98        4d2b0709.5116b  12628d  OK
12  1514        1514        4d2b0709.519e6  afd9ea  OK
13  1514        1514        4d2b0709.519f2  89da10  OK
14  1514        1514        4d2b0709.519fb  71da28  OK
15    66          66        4d2b0709.51c0d  d8292   OK
16  1514        1514        4d2b0709.51c1c  71da28  OK
17  1514        1514        4d2b0709.51c21  71da28  OK
18    66          66        4d2b0709.51c26  c8293   OK
19  1514        1514        4d2b0709.51c30  71da28  OK
20  1514        1514        4d2b0709.51c34  71da28  OK
21    66          66        4d2b0709.51cf2  d8292   OK
22  1514        9706        4d2b0709.51d01  30e8b29 OK
23  540422189       825240881       2.3130321aError reading file: /home/fklassen/Downloads/poc.pcap: Invalid argument

@fklassen fklassen added the 4.1.1 label Dec 15, 2015
@fklassen fklassen modified the milestone: 4.1.1 Dec 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants