stack-buffer-overflow in gf_text_get_utf8_line in gpac/gpac
Reported on
Oct 13th 2023
Description
stack-buffer-overflow in gf_text_get_utf8_line at filters/load_text.c:381.
#Version
git log
commit 7edc40feef23efd8c9948292d269eae76fa475af (HEAD -> master, origin/master, origin/HEAD)
Author: jeanlf <jeanlf@gpac.io>
Date: Thu Oct 12 16:58:53 2023 +0200
./bin/gcc/MP4Box -version
MP4Box - GPAC version 2.3-DEV-rev588-g7edc40fee-master
(c) 2000-2023 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io
Proof of Concept
./bin/gcc/MP4Box -dash 1000 /home/fuzz/crashes/sbo3
[Dasher] No template assigned, using $File$_dash$FS$$Number$
[Dasher] No bitrate property assigned to PID sbo_381, computing from bitstream
[TXTIn] Bad SRT formatting - expecting number got "m[ññ<?xml versi0"A217Z" minimumU.(17Z --> wi"
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame 0 after frame 0
[TXTIn] Error scanning SRT frame 0 timing
[TXTIn] Corrupted SRT frame -1 after frame 0
=================================================================
==59407==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffffffed310 at pc 0x7ffff761f16d bp 0x7ffffffebfe0 sp 0x7ffffffeb788
WRITE of size 2048 at 0x7ffffffed310 thread T0
#0 0x7ffff761f16c in __interceptor_strcpy ../../../../src/libsanitizer/asan/asan_interceptors.cc:431
#1 0x7ffff4d52d1c in strcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:90
#2 0x7ffff4d52d1c in gf_text_get_utf8_line filters/load_text.c:381
#3 0x7ffff4d71af3 in txtin_process_srt filters/load_text.c:996
#4 0x7ffff4d6b4f3 in txtin_process filters/load_text.c:4015
#5 0x7ffff4a5d4ae in gf_filter_process_task filter_core/filter.c:2971
#6 0x7ffff4a2ab11 in gf_fs_thread_proc filter_core/filter_session.c:2105
#7 0x7ffff4a2f8b6 in gf_fs_run filter_core/filter_session.c:2405
#8 0x7ffff43bc0bd in gf_dasher_process media_tools/dash_segmenter.c:1236
#9 0x555555621d26 in do_dash /home/fuzz/gpac/applications/mp4box/mp4box.c:4831
#10 0x555555621d26 in mp4box_main /home/fuzz/gpac/applications/mp4box/mp4box.c:6245
#11 0x7ffff164c082 in __libc_start_main ../csu/libc-start.c:308
#12 0x5555555fa05d in _start (/home/fuzz/gpac/bin/gcc/MP4Box+0xa605d)
Address 0x7ffffffed310 is located in stack of thread T0 at offset 2336 in frame
#0 0x7ffff4d708ef in txtin_process_srt filters/load_text.c:949
This frame has 14 object(s):
[32, 36) 'sh' (line 950)
[48, 52) 'sm' (line 950)
[64, 68) 'ss' (line 950)
[80, 84) 'sms' (line 950)
[96, 100) 'eh' (line 950)
[112, 116) 'em' (line 950)
[128, 132) 'es' (line 950)
[144, 148) 'ems' (line 950)
[160, 164) 'char_len' (line 950)
[176, 180) 'set_start_char' (line 951)
[192, 196) 'set_end_char' (line 951)
[208, 212) 'line' (line 952)
[224, 248) '<unknown>'
[288, 2336) 'szLine' (line 953) <== Memory access at offset 2336 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)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/asan/asan_interceptors.cc:431 in __interceptor_strcpy
Shadow bytes around the buggy address:
0x10007fff5a10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff5a20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff5a30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff5a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff5a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff5a60: 00 00[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
0x10007fff5a70: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff5a80: 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 04 f2
0x10007fff5a90: 04 f2 00 00 00 f2 f2 f2 f2 f2 00 00 00 f3 f3 f3
0x10007fff5aa0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff5ab0: 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
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
==59407==ABORTING
POC address:
https://github.com/Janette88/test_pocs/blob/main/sbo3
Impact
This is capable of causing crashes and allowing modification of stack memory which could lead to remote code execution.
SECURITY.md exists
2 months ago
I've updated the severity to a value better suited with the risk. Let me know if you don't agree.
Here is some references about CVSS Score. Pls check: https://nvd.nist.gov/vuln-metrics/cvss https://www.first.org/cvss/v3.1/examples https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System#Version_3.1
Stack overflow is a classic vulnerability . Maybe at the hacker's point of view, they could cause some serious problem by using this type of vulnerability ,even execute remote code.
We'd be happy to have an updated expert view on this.
On one hand it is great to have all these crashes reported (thank you!) because there might hide real security (and stability) concerns. So initially we didn't take much care to the severity score, we trusted the researchers.
On the other hand the Debian maintainers kicked our project out of older distributions because of severe security reports. The investigation with a professional agency showed that the scores were just too high. So we've started to have a look of the severity score.
The immense majority of the crashes reported here are discovered by fuzzers. They come with no evidence that they could be exploited somehow. It would be super helpful to show us how this issue could lead to an exploit. That would certainly help us a lot (and we would happy raise the severity score in this case!).
Totally understand what you mentioned as above. It is a common problem between the manufacturer and the security researcher. Also there is a gap between the software developer and the security researcher(including expert in Attack and Defense) because of different view.
The LINK introduced stack buffer overflow attack： https://www.rapid7.com/blog/post/2019/02/19/stack-based-buffer-overflow-attacks-what-you-need-to-know/
In our case , according to asan hints ,set breakpoints at filters/load_text.c:381 filters/load_text.c:949 filters/load_text.c:996 ,. it occures stack overflow when strcpy(szLine, szLineConv);
If you agree this vulnerability has the similar root cause (stack buffer overflow) as the link described after tracking the bug, there is the greater possibility to finish similare exploting attack with similar method.
we're happy to submit the bug report in our spare time to make the product safer .But we can not spend more time in writting exploit code to prove the risk. You're free to give a score you valued , we accept it :-)
Hi, thank you for the nice message and the link. Some students also tried to exploit parts of GPAC to no avail, but we should give a try. The issue is that as an open-source software, we have limited ressources to pay professionals for this. That's why your inputs are valuable. Thanks.
@admin @gpac no one response for question here ? can we get a CVE for this report?
No problem on our side. I definitely don't know what's happened recently with this but that's a regression @admin.
This report had been verified and it is valid. can we get a CVE for this report ? @gpac