OOB Read segfault in gpac/gpac
Reported on
May 18th 2023
Environment
Distributor ID: Debian
Description: Debian GNU/Linux bookworm/sid
Release: n/a
Codename: bookworm
Version
I checked against the latest release as of 05/18/23 the current master branch at commit a6ae93532ea5615c876c81a6580badbfa01d4383 .
Description
This AddressSanitizer output is indicating that an out of bounds read occurred in the function gf_filter_get_stats at line 4149 in the file filter_session.c. A bit of debugging leads me to think that the loop at line line 4131 is improperly bounded since at the crash, the loop iterator i
equals 0xffff4f07
for (i=0; i<f->num_input_pids; i++)
POC
AFL_MAP_SIZE=260000 ./MP4Box -dash 1000 ./crash_file
ASAN
[Dasher] No template assigned, using $File$_dash$FS$$Number$
Failed to connect filter fin PID crash_file to filter rfmpgvid: Feature Not Supported
Blacklisting rfmpgvid as output from fin and retrying connections
[MP4Mux] muxing codecID 0 not yet implemented - patch welcome
Failed to connect filter dasher PID crash_file to filter mp4mx: Feature Not Supported
Blacklisting mp4mx as output from dasher and retrying connections
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2980979==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000009c (pc 0x7ffff6d5968a bp 0x0c2600000200 sp 0x7fffffff4f90 T0)
==2980979==The signal is caused by a READ memory access.
==2980979==Hint: address points to the zero page.
#0 0x7ffff6d5968a in gf_filter_get_stats /path/to/gpac/src/filter_core/filter_session.c:4149:32
#1 0x7ffff660b68b in on_dasher_event /path/to/gpac/src/media_tools/dash_segmenter.c:501:8
#2 0x7ffff6d51fc9 in gf_fs_ui_event /path/to/gpac/src/filter_core/filter_session.c:4180:8
#3 0x7ffff6d831da in gf_filter_update_status /path/to/gpac/src/filter_core/filter.c:4738:2
#4 0x7ffff6f74b0a in filein_process /path/to/gpac/src/filters/in_file.c:699:3
#5 0x7ffff6d74d05 in gf_filter_process_task /path/to/gpac/src/filter_core/filter.c:2894:7
#6 0x7ffff6d4153c in gf_fs_thread_proc /path/to/gpac/src/filter_core/filter_session.c:1962:3
#7 0x7ffff6d3fd2f in gf_fs_run /path/to/gpac/src/filter_core/filter_session.c:2264:3
#8 0x7ffff660245a in gf_dasher_process /path/to/gpac/src/media_tools/dash_segmenter.c:1236:6
#9 0x5555556c15fc in do_dash /path/to/gpac/applications/mp4box/mp4box.c:4825:15
#10 0x5555556b2a8e in mp4box_main /path/to/gpac/applications/mp4box/mp4box.c:6236:7
#11 0x7ffff5846189 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#12 0x7ffff5846244 in __libc_start_main csu/../csu/libc-start.c:381:3
#13 0x5555555dad30 in _start (/path/to/gpac/new_pull_2_build/bin/gcc/MP4Box+0x86d30) (BuildId: 764c86f2d59b4db3d4590a720eca33bd143620a7)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /path/to/gpac/src/filter_core/filter_session.c:4149:32 in gf_filter_get_stats
==2980979==ABORTING
Impact
out of bounds read can cause a crash which will affect the system availability or potentially leak memory from the application.
Occurrences
filter_session.c L4131-L4149
Beginning of loop to where the crash triggers.
https://github.com/gpac/gpac/issues/2475
We've always been open to CVE reports. However due to recent discussions with Linux distribution maintainers, we need to understand high CVSS. Could you elaborate how you computed your score?
I think that the cvss score of this is lower, I agree. As a submission through huntr.dev you have to use a cvss calculator, the "Integrity" and "availability" in this calculator are set to high, which causes the score to be inflated in my opinion. Cvss is difficult determine with this calculator and devoid of context. I'm willing to edit the score and categories how you see fit. I think lowering the integrity score sounds reasonable. Let me know what you think.
Thanks. @admin If there is anything you can do to help reporters and maintainers set appropriate CVSS, please do.
The CVSS is 6.1 after adjustment. If that sounds correct to you, admin and maintainer(s) can proceed.