irontec/sngrep

stack-buffer-overflow /home/root/Compile/sngrep-1.7.0/src/capture.c:565 in capture_packet_reasm_ip

shinibufa opened this issue · 3 comments

Hello, developers of sngrep. We recently conducted a fuzz test on sngrep - 1.7.0 and discovered a stack-buffer-overflow bug. We would like to provide you with a description of this bug in order to assist you in resolving it.

Version:
sngrep - 1.7.0
ubuntu 20.04

command to reproduce:
sngrep -N -I Poc

ASAN report:
==3447928==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f0f636fece4 at pc 0x55986380b1f1 bp 0x7f0f636f99f0 sp 0x7f0f636f99e0
READ of size 1 at 0x7f0f636fece4 thread T1
#0 0x55986380b1f0 in capture_packet_reasm_ip /home/root/Compile/sngrep-1.7.0/src/capture.c:565
#1 0x55986380a4c3 in parse_packet /home/root/Compile/sngrep-1.7.0/src/capture.c:367
#2 0x7f0f66ec2466 (/lib/x86_64-linux-gnu/libpcap.so.0.8+0x23466)
#3 0x7f0f66eb0f67 in pcap_loop (/lib/x86_64-linux-gnu/libpcap.so.0.8+0x11f67)
#4 0x55986380e189 in capture_thread /home/root/Compile/sngrep-1.7.0/src/capture.c:1055
#5 0x7f0f66e84608 in start_thread /build/glibc-5hggjy/glibc-2.31/nptl/pthread_create.c:477
#6 0x7f0f66da9132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132)

Address 0x7f0f636fece4 is located in stack of thread T1 at offset 20628 in frame
#0 0x55986380a17f in parse_packet /home/root/Compile/sngrep-1.7.0/src/capture.c:321

This frame has 3 object(s):
[32, 36) 'size_capture' (line 337)
[48, 52) 'size_payload' (line 339)
[64, 20544) 'data' (line 333) <== Memory access at offset 20628 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions are supported)
Thread T1 created by T0 here:
#0 0x7f0f66fa5815 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208
#1 0x55986380e054 in capture_launch_thread /home/root/Compile/sngrep-1.7.0/src/capture.c:1040
#2 0x55986381b029 in main /home/root/Compile/sngrep-1.7.0/src/main.c:451
#3 0x7f0f66cae082 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: stack-buffer-overflow /home/root/Compile/sngrep-1.7.0/src/capture.c:565 in capture_packet_reasm_ip
Shadow bytes around the buggy address:
0x0fe26c6d7d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe26c6d7d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe26c6d7d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe26c6d7d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe26c6d7d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe26c6d7d90: 00 00 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3[f3]f3 f3 f3
0x0fe26c6d7da0: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
0x0fe26c6d7db0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe26c6d7dc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe26c6d7dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe26c6d7de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Is this related to, or a regression of #431?

Kaian commented

Hi @shinibufa

Thanks a lot for reporting! Above commit should fix the problem!

Is this related to, or a regression of #431?

It's similar but not the exact same check.

This issue is caused by trusting the NFLOG headers values and not checking if the reported size makes sense with the captured payload. In #431, the IP header reports a header size but there is not actually enough packet payload to contain a whole IP Header. Maybe the code can be refactorized to validate both conditions in a single check, not sure.

Regards!

Thanks for replying.