irontec / sngrep

Ncurses SIP Messages flow viewer
GNU General Public License v3.0
1.01k stars 189 forks source link

[SECURITY] heap-buffer-overflow RTP.c #481

Closed RootUp closed 5 months ago

RootUp commented 5 months ago

Summary:

While fuzzing a heap-buffer-overflow error in sngrep while processing a malformed SIP packet, caused by accessing memory beyond allocated bounds in the rtp_check_packet function.

Affected version/Tested on:

sngrep - 1.8.1 
5.4.0-174-generic #193-Ubuntu SMP

ASAN:

Dialog count: 0=================================================================
==728054==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040000029c0 at pc 0x0000004e34f6 bp 0x7ffff46f9570 sp 0x7ffff46f9568
READ of size 4 at 0x6040000029c0 thread T1
    #0 0x4e34f5 in rtp_check_packet /sngrep/src/rtp.c:275:25
    #1 0x4cb08c in capture_packet_parse /sngrep/src/capture.c:993:23
    #2 0x4c84a4 in parse_packet /sngrep/src/capture.c:455:9
    #3 0x7ffff7f13466  (/lib/x86_64-linux-gnu/libpcap.so.0.8+0x23466)
    #4 0x7ffff7f01f67 in pcap_loop (/lib/x86_64-linux-gnu/libpcap.so.0.8+0x11f67)
    #5 0x4c76ab in capture_thread /sngrep/src/capture.c:1069:5
    #6 0x7ffff7ed3608 in start_thread /build/glibc-wuryBv/glibc-2.31/nptl/pthread_create.c:477:8
    #7 0x7ffff7c7e352 in clone /build/glibc-wuryBv/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95

0x6040000029c0 is located 3 bytes to the right of 45-byte region [0x604000002990,0x6040000029bd)
allocated by thread T1 here:
    #0 0x49735d in malloc (/sngrep/src/sngrep+0x49735d)
    #1 0x4ce743 in packet_set_payload /sngrep/src/packet.c:145:27

Thread T1 created by T0 here:
    #0 0x48210a in pthread_create (/sngrep/src/sngrep+0x48210a)
    #1 0x4cb93f in capture_launch_thread /sngrep/src/capture.c:1054:13
    #2 0x4d7616 in main /sngrep/src/main.c:451:9
    #3 0x7ffff7b83082 in __libc_start_main /build/glibc-wuryBv/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /sngrep/src/rtp.c:275:25 in rtp_check_packet
Shadow bytes around the buggy address:
  0x0c087fff84e0: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fa
  0x0c087fff84f0: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 fa
  0x0c087fff8500: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8510: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 fa
  0x0c087fff8520: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
=>0x0c087fff8530: fa fa 00 00 00 00 00 05[fa]fa fa fa fa fa fa fa
  0x0c087fff8540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff8580: 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
==728054==ABORTING
Kaian commented 5 months ago

Hi @RootUp !

Could you provide some script or pcap to reproduce this problem and test possible fixes?

Thanks for the bug report!

RootUp commented 5 months ago

Hi @Kaian

Sure, sample.pcap.zip

Kaian commented 5 months ago

Hi!

Sorry for the late response.

Above commit should fix this problem by properly checking the payload size is enough while parsing RTCP headers. I will try to make a patch version soon with this change.

Thanks a lot for reporting!!

RootUp commented 5 months ago

Thank you.!