GPAC 2.1-DEV-rev368-gfd054169b-master was discovered to contain a segmentation violation via the function gf_dump_vrml_sffield at /scene_manager/scene_dump.c.

**Description**

SEGV scene\_manager/scene\_dump.c:693 in gf\_dump\_vrml\_sffield

**Version**

    $ ./MP4Box -version
    MP4Box - GPAC version 2.1-DEV-rev368-gfd054169b-master
    (c) 2000-2022 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io
    
    Please cite our work in your research:
            GPAC Filters: https://doi.org/10.1145/3339825.3394929
            GPAC: https://doi.org/10.1145/1291233.1291452
    
    GPAC Configuration: --enable-sanitizer
    Features: GPAC_CONFIG_LINUX GPAC_64_BITS GPAC_HAS_IPV6 GPAC_HAS_SOCK_UN GPAC_MINIMAL_ODF GPAC_HAS_QJS GPAC_HAS_JPEG GPAC_HAS_PNG GPAC_HAS_LINUX_DVB  GPAC_DISABLE_3D 
    

**Replay**

    git clone https://github.com/gpac/gpac.git
    cd gpac
    ./configure --enable-sanitizer
    make -j$(nproc)
    ./bin/gcc/MP4Box -bt mp4box-bt-segv-1
    

**POC**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/gpac/mp4box-bt-segv-1

**ASAN**

    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent minf
    [iso file] Missing DataInformationBox
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Read Box type 0000 (0x30303030) at position 11542 has size 0 but is not at root/file level. Forbidden, skipping end of parent box !
    [iso file] Box "moov" (start 20) has 806 extra bytes
    [iso file] Unknown top-level box type 0000
    [iso file] Incomplete box 0000 - start 12356 size 808358436
    [iso file] Incomplete file while reading for dump - aborting parsing
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent minf
    [iso file] Missing DataInformationBox
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Read Box type 0000 (0x30303030) at position 11542 has size 0 but is not at root/file level. Forbidden, skipping end of parent box !
    [iso file] Box "moov" (start 20) has 806 extra bytes
    [iso file] Unknown top-level box type 0000
    [iso file] Incomplete box 0000 - start 12356 size 808358436
    [iso file] Incomplete file while reading for dump - aborting parsing
    MPEG-4 BIFS Scene Parsing
    [ODF] Reading bifs config: shift in sizes (not supported)
    [MP4 Loading] Unable to fetch sample 38 from track ID 8 - aborting track import
    Scene loaded - dumping 1 systems streams
    ASAN:DEADLYSIGNAL
    =================================================================
    ==42376==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f6a20c34c94 bp 0x60b000000720 sp 0x7ffd44396130 T0)
    ==42376==The signal is caused by a READ memory access.
    ==42376==Hint: address points to the zero page.
        #0 0x7f6a20c34c93 in gf_dump_vrml_sffield scene_manager/scene_dump.c:693
        #1 0x7f6a20c69012 in gf_dump_vrml_simple_field scene_manager/scene_dump.c:775
        #2 0x7f6a20c5020c in DumpXReplace scene_manager/scene_dump.c:2291
        #3 0x7f6a20c5020c in gf_sm_dump_command_list scene_manager/scene_dump.c:2901
        #4 0x7f6a20c77d57 in gf_sm_dump scene_manager/scene_dump.c:3519
        #5 0x556786082cef in dump_isom_scene /home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/applications/mp4box/filedump.c:221
        #6 0x55678605d7ff in mp4box_main /home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/applications/mp4box/mp4box.c:6336
        #7 0x7f6a1f3bac86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #8 0x55678602f0a9 in _start (/home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/bin/gcc/MP4Box+0x4e0a9)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV scene_manager/scene_dump.c:693 in gf_dump_vrml_sffield
    ==42376==ABORTING
    

**Environment**

    Ubuntu 16.04
    Clang 10.0.1
    gcc 5.5

CVE-2022-43045: SEGV scene_manager/scene_dump.c:693 in gf_dump_vrml_sffield · Issue #2277 · gpac/gpac

GPAC 2.1-DEV-rev368-gfd054169b-master was discovered to contain a segmentation violation via the function BD_CheckSFTimeOffset at /bifs/field_decode.c.

**Description**

SEGV in BD\_CheckSFTimeOffset bifs/field\_decode.c:58

**Version**

    $ ./MP4Box -version
    MP4Box - GPAC version 2.1-DEV-rev368-gfd054169b-master
    (c) 2000-2022 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io
    
    Please cite our work in your research:
            GPAC Filters: https://doi.org/10.1145/3339825.3394929
            GPAC: https://doi.org/10.1145/1291233.1291452
    
    GPAC Configuration: --enable-sanitizer
    Features: GPAC_CONFIG_LINUX GPAC_64_BITS GPAC_HAS_IPV6 GPAC_HAS_SOCK_UN GPAC_MINIMAL_ODF GPAC_HAS_QJS GPAC_HAS_JPEG GPAC_HAS_PNG GPAC_HAS_LINUX_DVB  GPAC_DISABLE_3D 
    

**Replay**

    git clone https://github.com/gpac/gpac.git
    cd gpac
    ./configure --enable-sanitizer
    make -j$(nproc)
    ./bin/gcc/MP4Box -bt mp4box-bt-segv-0
    

**POC**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/gpac/mp4box-bt-segv-0

**ASAN**

    
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent minf
    [iso file] Missing DataInformationBox
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Read Box type 0000 (0x30303030) at position 11542 has size 0 but is not at root/file level. Forbidden, skipping end of parent box !
    [iso file] Box "moov" (start 20) has 806 extra bytes
    [iso file] Unknown top-level box type 0000
    [iso file] Incomplete box 0000 - start 12356 size 808358436
    [iso file] Incomplete file while reading for dump - aborting parsing
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Unknown box type 0000 in parent minf
    [iso file] Missing DataInformationBox
    [iso file] Unknown box type 0000 in parent moov
    [iso file] Read Box type 0000 (0x30303030) at position 11542 has size 0 but is not at root/file level. Forbidden, skipping end of parent box !
    [iso file] Box "moov" (start 20) has 806 extra bytes
    [iso file] Unknown top-level box type 0000
    [iso file] Incomplete box 0000 - start 12356 size 808358436
    [iso file] Incomplete file while reading for dump - aborting parsing
    MPEG-4 BIFS Scene Parsing
    [ODF] Reading bifs config: shift in sizes (not supported)
    ASAN:DEADLYSIGNAL                 | (00/100)
    =================================================================
    ==64022==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7f4bf2457608 bp 0x7fff7805fc00 sp 0x7fff7805f360 T0)
    ==64022==The signal is caused by a READ memory access.
    ==64022==Hint: address points to the zero page.
        #0 0x7f4bf2457607  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5b607)
        #1 0x7f4befd4dd1a in BD_CheckSFTimeOffset bifs/field_decode.c:58
        #2 0x7f4befd53e80 in gf_bifs_dec_sf_field bifs/field_decode.c:105
        #3 0x7f4befd6a1be in BM_XReplace bifs/memory_decoder.c:355
        #4 0x7f4befd6a1be in BM_ParseExtendedUpdates bifs/memory_decoder.c:398
        #5 0x7f4befd754ad in BM_ParseInsert bifs/memory_decoder.c:586
        #6 0x7f4befd754ad in BM_ParseCommand bifs/memory_decoder.c:908
        #7 0x7f4befd7660d in gf_bifs_decode_command_list bifs/memory_decoder.c:1038
        #8 0x7f4bf0743bc6 in gf_sm_load_run_isom scene_manager/loader_isom.c:303
        #9 0x562cf53f8dd7 in dump_isom_scene /home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/applications/mp4box/filedump.c:207
        #10 0x562cf53d37ff in mp4box_main /home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/applications/mp4box/mp4box.c:6336
        #11 0x7f4beef6ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #12 0x562cf53a50a9 in _start (/home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/bin/gcc/MP4Box+0x4e0a9)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5b607) 
    ==64022==ABORTING
    

**Environment**

    Ubuntu 16.04
    Clang 10.0.1
    gcc 5.5

CVE-2022-43043: SEGV BD_CheckSFTimeOffset bifs/field_decode.c:58 · Issue #2276 · gpac/gpac

An issue was discovered in Bento4 v1.6.0-639. There is a heap-buffer-overflow in AP4_Dec3Atom::AP4_Dec3Atom at Ap4Dec3Atom.cpp, leading to a Denial of Service (DoS), as demonstrated by mp42aac.

Hi, developers of Bento4:  
Thanks for your fix of issue #751  
In the test of the binary mp42aac instrumented with ASAN. There are some inputs causing heap-buffer-overflow. Here is the ASAN mode output:

\==27304==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000ed28 at pc 0x0000005a64d9 bp 0x7fffffffb290 sp 0x7fffffffb280  
READ of size 1 at 0x60300000ed28 thread T0  
#0 0x5a64d8 in AP4\_Dec3Atom::AP4\_Dec3Atom(unsigned int, unsigned char const\*) /root/Bento4/Source/C++/Core/Ap4Dec3Atom.cpp:161  
#1 0x5a6a62 in AP4\_Dec3Atom::Create(unsigned int, AP4\_ByteStream&) /root/Bento4/Source/C++/Core/Ap4Dec3Atom.cpp:56  
#2 0x508887 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:769  
#3 0x50ecb6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#4 0x579928 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#5 0x480e69 in AP4\_SampleEntry::Read(AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:115  
#6 0x480e69 in AP4\_AudioSampleEntry::AP4\_AudioSampleEntry(unsigned int, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:420  
#7 0x480e69 in AP4\_Eac3SampleEntry::AP4\_Eac3SampleEntry(unsigned int, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:752  
#8 0x508d6b in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:338  
#9 0x50ecb6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#10 0x490228 in AP4\_StsdAtom::AP4\_StsdAtom(unsigned int, unsigned char, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4StsdAtom.cpp:101  
#11 0x491bd0 in AP4\_StsdAtom::Create(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4StsdAtom.cpp:57  
#12 0x50aaae in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:458  
#13 0x50ecb6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#14 0x577862 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#15 0x577862 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#16 0x5785a6 in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#17 0x507f53 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#18 0x50ecb6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#19 0x5aea82 in AP4\_DrefAtom::AP4\_DrefAtom(unsigned int, unsigned char, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4DrefAtom.cpp:84  
#20 0x5aeff7 in AP4\_DrefAtom::Create(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4DrefAtom.cpp:50  
#21 0x509882 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:580  
#22 0x50ecb6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#23 0x577862 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#24 0x577862 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#25 0x5785a6 in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#26 0x507f53 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#27 0x50ecb6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#28 0x577862 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#29 0x577862 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#30 0x5785a6 in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#31 0x507f53 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#32 0x50ecb6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#33 0x577862 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#34 0x577862 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#35 0x5785a6 in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#36 0x507f53 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#37 0x50dd7a in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#38 0x50dd7a in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:154  
#39 0x418daf in AP4\_File::ParseStream(AP4\_ByteStream&, AP4\_AtomFactory&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:104  
#40 0x418daf in AP4\_File::AP4\_File(AP4\_ByteStream&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:78  
#41 0x4040d7 in main /root/Bento4/Source/C++/Apps/Mp42Aac/Mp42Aac.cpp:250  
#42 0x7ffff61bb83f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#43 0x408508 in \_start (/root/Bento4/mp42aac+0x408508)

0x60300000ed28 is located 0 bytes to the right of 24-byte region \[0x60300000ed10,0x60300000ed28)  
allocated by thread T0 here:  
#0 0x7ffff6f03712 in operator new\[\](unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99712)  
#1 0x4147b5 in AP4\_DataBuffer::AP4\_DataBuffer(unsigned int) /root/Bento4/Source/C++/Core/Ap4DataBuffer.cpp:55  
#2 0x17 ()

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/Bento4/Source/C++/Core/Ap4Dec3Atom.cpp:161 AP4\_Dec3Atom::AP4\_Dec3Atom(unsigned int, unsigned char const\*)  
Shadow bytes around the buggy address:  
0x0c067fff9d50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 fa  
\=>0x0c067fff9da0: fa fa 00 00 00\[fa\]fa fa 00 00 00 fa fa fa 00 00  
0x0c067fff9db0: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa  
0x0c067fff9dc0: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa  
0x0c067fff9dd0: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00  
0x0c067fff9de0: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa  
0x0c067fff9df0: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 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  
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  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
\==27304==ABORTING

**Crash input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/Bento4/mp42aac-hbo-00

**Validation steps**

git clone https://github.com/axiomatic-systems/Bento4  
cd Bento4/  
mkdir check\_build && cd check\_build  
cmake ../ -DCMAKE\_C\_COMPILER=clang -DCMAKE\_CXX\_COMPILER=clang++ -DCMAKE\_C\_FLAGS="-fsanitize=address" -DCMAKE\_CXX\_FLAGS="-fsanitize=address" -DCMAKE\_BUILD\_TYPE=Release  
make -j  
./mp42aac mp42aac-hbo-00 /dev/null

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2022-43035: Heap-buffer-overflow with ASAN in mp42aac · Issue #762 · axiomatic-systems/Bento4

Bento4 v1.6.0-639 was discovered to contain a heap overflow via the AP4_BitReader::ReadCache() function in mp42ts.

Hi, developers of Bento4:  
In the test of the binary mp42ts instrumented with ASAN. There are some inputs causing heap-buffer-overflow. Here is the ASAN mode output. The output is different from #764

\=================================================================  
\==3902==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400000df38 at pc 0x0000004a51a6 bp 0x7ffc109910f0 sp 0x7ffc109910e0  
READ of size 1 at 0x60400000df38 thread T0  
#0 0x4a51a5 in AP4\_BitReader::ReadCache() const /root/Bento4/Source/C++/Core/Ap4Utils.cpp:447  
#1 0x4a51a5 in AP4\_BitReader::ReadBits(unsigned int) /root/Bento4/Source/C++/Core/Ap4Utils.cpp:467  
#2 0x5405fc in AP4\_Dac4Atom::AP4\_Dac4Atom(unsigned int, unsigned char const\*) /root/Bento4/Source/C++/Core/Ap4Dac4Atom.cpp:313  
#3 0x5423a2 in AP4\_Dac4Atom::Create(unsigned int, AP4\_ByteStream&) /root/Bento4/Source/C++/Core/Ap4Dac4Atom.cpp:58  
#4 0x4f47c5 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:776  
#5 0x4f955a in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#6 0x51a25e in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#7 0x487d31 in AP4\_SampleEntry::Read(AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:115  
#8 0x487d31 in AP4\_AudioSampleEntry::AP4\_AudioSampleEntry(unsigned int, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:420  
#9 0x487d31 in AP4\_Ac4SampleEntry::AP4\_Ac4SampleEntry(unsigned int, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:801  
#10 0x4f1aad in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:342  
#11 0x4f955a in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#12 0x6134a9 in AP4\_StsdAtom::AP4\_StsdAtom(unsigned int, unsigned char, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4StsdAtom.cpp:101  
#13 0x61534b in AP4\_StsdAtom::Create(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4StsdAtom.cpp:57  
#14 0x4f55a6 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:458  
#15 0x4f955a in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#16 0x5181d5 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#17 0x5181d5 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#18 0x518fce in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#19 0x4f2b69 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#20 0x4f865c in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#21 0x4f865c in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:154  
#22 0x41c87f in AP4\_File::ParseStream(AP4\_ByteStream&, AP4\_AtomFactory&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:104  
#23 0x41c87f in AP4\_File::AP4\_File(AP4\_ByteStream&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:78  
#24 0x40441f in main /root/Bento4/Source/C++/Apps/Mp42Ts/Mp42Ts.cpp:511  
#25 0x7fb1c343783f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#26 0x40ad98 in \_start (/root/Bento4/mp42ts+0x40ad98)

0x60400000df38 is located 0 bytes to the right of 40-byte region \[0x60400000df10,0x60400000df38)  
allocated by thread T0 here:  
#0 0x7fb1c417f712 in operator new\[\](unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99712)  
#1 0x4199e5 in AP4\_DataBuffer::ReallocateBuffer(unsigned int) /root/Bento4/Source/C++/Core/Ap4DataBuffer.cpp:210  
#2 0x4199e5 in AP4\_DataBuffer::SetBufferSize(unsigned int) /root/Bento4/Source/C++/Core/Ap4DataBuffer.cpp:136

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/Bento4/Source/C++/Core/Ap4Utils.cpp:447 AP4\_BitReader::ReadCache() const  
Shadow bytes around the buggy address:  
0x0c087fff9b90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c087fff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c087fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c087fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c087fff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
\=>0x0c087fff9be0: fa fa 00 00 00 00 00\[fa\]fa fa 00 00 00 00 06 fa  
0x0c087fff9bf0: fa fa 00 00 00 00 06 fa fa fa 00 00 00 00 00 00  
0x0c087fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c087fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c087fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c087fff9c30: 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  
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  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
\==3902==ABORTING

**Crash input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/Bento4/mp42ts-hbo-01

**Validation steps**

git clone https://github.com/axiomatic-systems/Bento4  
cd Bento4/  
mkdir check\_build && cd check\_build  
cmake ../ -DCMAKE\_C\_COMPILER=clang -DCMAKE\_CXX\_COMPILER=clang++ -DCMAKE\_C\_FLAGS="-fsanitize=address" -DCMAKE\_CXX\_FLAGS="-fsanitize=address" -DCMAKE\_BUILD\_TYPE=Release  
make -j  
./mp42ts mp42ts-hbo-01 /dev/null

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2022-43038: Heap-buffer-overflow with ASAN in mp42ts · Issue #787 · axiomatic-systems/Bento4

An issue was discovered in Bento4 1.6.0-639. There is a memory leak in the function AP4_File::ParseStream in /Core/Ap4File.cpp.

Hi, developers of Bento4:  
In the test of the binary mp42aac instrumented with ASAN. There are some inputs causing memory leaks. Here is the ASAN mode output. The output is different from #763.

\=================================================================  
\==6659==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 64 byte(s) in 1 object(s) allocated from:  
#0 0x7f8d891f0592 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99592)  
#1 0x418dff in AP4\_File::ParseStream(AP4\_ByteStream&, AP4\_AtomFactory&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:108  
#2 0x418dff in AP4\_File::AP4\_File(AP4\_ByteStream&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:78

SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).

**Crash Input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/Bento4/mp42aac-ml-01

**Verification steps：**

git clone https://github.com/axiomatic-systems/Bento4  
cd Bento4/  
mkdir check\_build && cd check\_build  
cmake ../ -DCMAKE\_C\_COMPILER=clang -DCMAKE\_CXX\_COMPILER=clang++ -DCMAKE\_C\_FLAGS="-fsanitize=address" -DCMAKE\_CXX\_FLAGS="-fsanitize=address" -DCMAKE\_BUILD\_TYPE=Release  
make -j  
./mp42aac mp42aac-ml-01 /dev/null

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2022-43037: Memory leaks with ASAN in mp42aac · Issue #788 · axiomatic-systems/Bento4

An issue was discovered in Bento4 v1.6.0-639. There is a heap buffer overflow vulnerability in the AP4_BitReader::SkipBits(unsigned int) function in mp42ts.

Hi, developers of Bento4:  
In the test of the binary mp42ts instrumented with ASAN. There are some inputs causing heap-buffer-overflow. Here is the ASAN mode output:

\==10897==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000ec3c at pc 0x0000004a9771 bp 0x7fffffffb150 sp 0x7fffffffb140  
READ of size 4 at 0x60300000ec3c thread T0  
#0 0x4a9770 in AP4\_BitReader::SkipBits(unsigned int) /root/Bento4/Source/C++/Core/Ap4Utils.cpp:564  
#1 0x53f5c5 in AP4\_Dac4Atom::AP4\_Dac4Atom(unsigned int, unsigned char const\*) /root/Bento4/Source/C++/Core/Ap4Dac4Atom.cpp:396  
#2 0x543230 in AP4\_Dac4Atom::Create(unsigned int, AP4\_ByteStream&) /root/Bento4/Source/C++/Core/Ap4Dac4Atom.cpp:58  
#3 0x4f7503 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:776  
#4 0x4fc596 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#5 0x51cd08 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#6 0x4826d1 in AP4\_SampleEntry::Read(AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:115  
#7 0x4826d1 in AP4\_AudioSampleEntry::AP4\_AudioSampleEntry(unsigned int, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4SampleEntry.cpp:420  
#8 0x5d736d in AP4\_EncaSampleEntry::AP4\_EncaSampleEntry(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4Protection.cpp:74  
#9 0x4f4a3c in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:298  
#10 0x4fc596 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#11 0x614618 in AP4\_StsdAtom::AP4\_StsdAtom(unsigned int, unsigned char, unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4StsdAtom.cpp:101  
#12 0x615fc0 in AP4\_StsdAtom::Create(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4StsdAtom.cpp:57  
#13 0x4f838e in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:458  
#14 0x4fc596 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#15 0x51ac42 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#16 0x51ac42 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#17 0x51b986 in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#18 0x4f5833 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#19 0x4fc596 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#20 0x51ac42 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#21 0x51ac42 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#22 0x51b986 in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#23 0x4f5833 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#24 0x4fc596 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#25 0x51ac42 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#26 0x51ac42 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#27 0x51b986 in AP4\_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88  
#28 0x4f5833 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:816  
#29 0x4fc596 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#30 0x51ac42 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#31 0x51ac42 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#32 0x49cfb2 in AP4\_TrakAtom::AP4\_TrakAtom(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4TrakAtom.cpp:165  
#33 0x4f7709 in AP4\_TrakAtom::Create(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4TrakAtom.h:58  
#34 0x4f7709 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:413  
#35 0x4fc596 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#36 0x51ac42 in AP4\_ContainerAtom::ReadChildren(AP4\_AtomFactory&, AP4\_ByteStream&, unsigned long long) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194  
#37 0x51ac42 in AP4\_ContainerAtom::AP4\_ContainerAtom(unsigned int, unsigned long long, bool, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139  
#38 0x430fac in AP4\_MoovAtom::AP4\_MoovAtom(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4MoovAtom.cpp:80  
#39 0x4f5430 in AP4\_MoovAtom::Create(unsigned int, AP4\_ByteStream&, AP4\_AtomFactory&) /root/Bento4/Source/C++/Core/Ap4MoovAtom.h:56  
#40 0x4f5430 in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:393  
#41 0x4fb65a in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, unsigned long long&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234  
#42 0x4fb65a in AP4\_AtomFactory::CreateAtomFromStream(AP4\_ByteStream&, AP4\_Atom\*&) /root/Bento4/Source/C++/Core/Ap4AtomFactory.cpp:154  
#43 0x41c6af in AP4\_File::ParseStream(AP4\_ByteStream&, AP4\_AtomFactory&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:104  
#44 0x41c6af in AP4\_File::AP4\_File(AP4\_ByteStream&, bool) /root/Bento4/Source/C++/Core/Ap4File.cpp:78  
#45 0x404446 in main /root/Bento4/Source/C++/Apps/Mp42Ts/Mp42Ts.cpp:511  
#46 0x7ffff61bb83f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#47 0x40ae38 in \_start (/root/Bento4/mp42ts+0x40ae38)

0x60300000ec3c is located 0 bytes to the right of 28-byte region \[0x60300000ec20,0x60300000ec3c)  
allocated by thread T0 here:  
#0 0x7ffff6f03712 in operator new\[\](unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99712)  
#1 0x419645 in AP4\_DataBuffer::ReallocateBuffer(unsigned int) /root/Bento4/Source/C++/Core/Ap4DataBuffer.cpp:210  
#2 0x419645 in AP4\_DataBuffer::SetBufferSize(unsigned int) /root/Bento4/Source/C++/Core/Ap4DataBuffer.cpp:136

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/Bento4/Source/C++/Core/Ap4Utils.cpp:564 AP4\_BitReader::SkipBits(unsigned int)  
Shadow bytes around the buggy address:  
0x0c067fff9d30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fff9d70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
\=>0x0c067fff9d80: fa fa fa fa 00 00 00\[04\]fa fa 00 00 00 02 fa fa  
0x0c067fff9d90: 00 00 00 02 fa fa 00 00 00 fa fa fa 00 00 00 fa  
0x0c067fff9da0: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00  
0x0c067fff9db0: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa  
0x0c067fff9dc0: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa  
0x0c067fff9dd0: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 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  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
\==10897==ABORTING

**Crash input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/Bento4/mp42ts-hbo-00

**Validation steps**

git clone https://github.com/axiomatic-systems/Bento4  
cd Bento4/  
mkdir check\_build && cd check\_build  
cmake ../ -DCMAKE\_C\_COMPILER=clang -DCMAKE\_CXX\_COMPILER=clang++ -DCMAKE\_C\_FLAGS="-fsanitize=address" -DCMAKE\_CXX\_FLAGS="-fsanitize=address" -DCMAKE\_BUILD\_TYPE=Release  
make -j  
./mp42ts mp42ts-hbo-00 /dev/null

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2022-43034: Heap-buffer-overflow with ASAN in mp42ts · Issue #764 · axiomatic-systems/Bento4

An issue was discovered in Bento4 1.6.0-639. There is a bad free in the component AP4_HdlrAtom::~AP4_HdlrAtom() which allows attackers to cause a Denial of Service (DoS) via a crafted input.

Hi, developers of Bento4:  
In the test of the binary mp42aac instrumented with ASAN. There are some inputs causing attempting free on address which was not malloc. Here is the ASAN mode output:

\==9252==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x60200000ef50 in thread T0  
#0 0x7ffff6f03d0a in operator delete (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99d0a)  
#1 0x5c124b in AP4\_HdlrAtom::~AP4\_HdlrAtom() /root/Bento4/Source/C++/Core/Ap4HdlrAtom.h:61  
#2 0x5c124b in AP4\_HdlrAtom::~AP4\_HdlrAtom() /root/Bento4/Source/C++/Core/Ap4HdlrAtom.h:61  
#3 0x4e7e4b in AP4\_List<AP4\_Atom>::DeleteReferences() /root/Bento4/Source/C++/Core/Ap4List.h:476  
#4 0x4e7e4b in AP4\_AtomParent::~AP4\_AtomParent() /root/Bento4/Source/C++/Core/Ap4Atom.cpp:516  
#5 0x57a323 in AP4\_ContainerAtom::~AP4\_ContainerAtom() /root/Bento4/Source/C++/Core/Ap4ContainerAtom.h:48  
#6 0x57a323 in AP4\_ContainerAtom::~AP4\_ContainerAtom() /root/Bento4/Source/C++/Core/Ap4ContainerAtom.h:48  
#7 0x4e7e4b in AP4\_List<AP4\_Atom>::DeleteReferences() /root/Bento4/Source/C++/Core/Ap4List.h:476  
#8 0x4e7e4b in AP4\_AtomParent::~AP4\_AtomParent() /root/Bento4/Source/C++/Core/Ap4Atom.cpp:516  
#9 0x417b8d in AP4\_File::~AP4\_File() /root/Bento4/Source/C++/Core/Ap4File.cpp:84  
#10 0x417b8d in AP4\_File::~AP4\_File() /root/Bento4/Source/C++/Core/Ap4File.cpp:88  
#11 0x4043f2 in main /root/Bento4/Source/C++/Apps/Mp42Aac/Mp42Aac.cpp:303  
#12 0x7ffff61bb83f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#13 0x408508 in \_start (/root/Bento4/mp42aac+0x408508)

0x60200000ef50 is located 0 bytes inside of 1-byte region \[0x60200000ef50,0x60200000ef51)  
allocated by thread T0 here:  
#0 0x7ffff6f03712 in operator new\[\](unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99712)  
#1 0x48ac75 in AP4\_String::Assign(char const\*, unsigned int) /root/Bento4/Source/C++/Core/Ap4String.cpp:165  
#2 0x48ac75 in AP4\_String::operator=(char const\*) /root/Bento4/Source/C++/Core/Ap4String.cpp:123

SUMMARY: AddressSanitizer: bad-free ??:0 operator delete  
\==9252==ABORTING

**Crash input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/Bento4/mp42aac-badfree

**Validation steps**

git clone https://github.com/axiomatic-systems/Bento4  
cd Bento4/  
mkdir check\_build && cd check\_build  
cmake ../ -DCMAKE\_C\_COMPILER=clang -DCMAKE\_CXX\_COMPILER=clang++ -DCMAKE\_C\_FLAGS="-fsanitize=address" -DCMAKE\_CXX\_FLAGS="-fsanitize=address" -DCMAKE\_BUILD\_TYPE=Release  
make -j  
./mp42aac mp42aac-badfree /dev/null

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2022-43033: Bad-free with ASAN in mp42aac · Issue #765 · axiomatic-systems/Bento4

An issue was discovered in Bento4 v1.6.0-639. There is a memory leak in AP4_DescriptorFactory::CreateDescriptorFromStream in Core/Ap4DescriptorFactory.cpp, as demonstrated by mp42aac.

Hi, developers of Bento4:  
In the test of the binary mp42aac instrumented with ASAN. There are some inputs causing memory leaks. Here is the ASAN mode output:

\=================================================================  
\==19530==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 80 byte(s) in 1 object(s) allocated from:  
#0 0x7ffff6f03592 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99592)  
#1 0x5ad493 in AP4\_DescriptorFactory::CreateDescriptorFromStream(AP4\_ByteStream&, AP4\_Descriptor\*&) /root/Bento4/Source/C++/Core/Ap4DescriptorFactory.cpp:85

Indirect leak of 112 byte(s) in 2 object(s) allocated from:  
#0 0x7ffff6f03592 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99592)  
#1 0x5ad7a9 in AP4\_DescriptorFactory::CreateDescriptorFromStream(AP4\_ByteStream&, AP4\_Descriptor\*&) /root/Bento4/Source/C++/Core/Ap4DescriptorFactory.cpp:127

Indirect leak of 72 byte(s) in 3 object(s) allocated from:  
#0 0x7ffff6f03592 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99592)  
#1 0x604f8b in AP4\_List<AP4\_Descriptor>::Add(AP4\_Descriptor\*) /root/Bento4/Source/C++/Core/Ap4List.h:160  
#2 0x604f8b in AP4\_ObjectDescriptor::AP4\_ObjectDescriptor(AP4\_ByteStream&, unsigned char, unsigned int, unsigned int) /root/Bento4/Source/C++/Core/Ap4ObjectDescriptor.cpp:103

Indirect leak of 32 byte(s) in 1 object(s) allocated from:  
#0 0x7ffff6f03592 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99592)  
#1 0x5ad532 in AP4\_DescriptorFactory::CreateDescriptorFromStream(AP4\_ByteStream&, AP4\_Descriptor\*&) /root/Bento4/Source/C++/Core/Ap4DescriptorFactory.cpp:115

Indirect leak of 25 byte(s) in 2 object(s) allocated from:  
#0 0x7ffff6f03712 in operator new\[\](unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99712)  
#1 0x415b81 in AP4\_DataBuffer::ReallocateBuffer(unsigned int) /root/Bento4/Source/C++/Core/Ap4DataBuffer.cpp:210  
#2 0x415b81 in AP4\_DataBuffer::SetDataSize(unsigned int) /root/Bento4/Source/C++/Core/Ap4DataBuffer.cpp:151

SUMMARY: AddressSanitizer: 321 byte(s) leaked in 9 allocation(s).

**Crash Input**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/Bento4/mp42aac-ml-00

**Verification steps：**

git clone https://github.com/axiomatic-systems/Bento4  
cd Bento4/  
mkdir check\_build && cd check\_build  
cmake ../ -DCMAKE\_C\_COMPILER=clang -DCMAKE\_CXX\_COMPILER=clang++ -DCMAKE\_C\_FLAGS="-fsanitize=address" -DCMAKE\_CXX\_FLAGS="-fsanitize=address" -DCMAKE\_BUILD\_TYPE=Release  
make -j  
./mp42aac mp42aac-ml-00 /dev/null

**Environment**

Ubuntu 16.04  
Clang 10.0.1  
gcc 5.5

CVE-2022-43032: Memory leaks with ASAN in mp42aac · Issue #763 · axiomatic-systems/Bento4

The Winnti APT was spotted dropping several variants of Spyder Loader and other malware as part of the so-called Operation Cuckoobees.

The Winnti cyber-espionage group out of China was discovered deploying the Spyder Loader malware as part of an ongoing campaign to gather intelligence information on government organizations in Hong Kong.

Researchers at Symantec's Threat Hunter Team recently observed malicious activity in which attackers remained active on some targeted networks for more than a year to steal critical data in what they believe is an extension of the group's previously identified Operation Cuckoobees, they said in a blog post published this week.

"While we did not see the ultimate payload in this campaign, based on the previous activity seen alongside the Spyder Loader malware it seems likely the ultimate goal of this activity was intelligence collection," researchers wrote.

Researchers at Cybereason first identified the Cuckoobees campaign in May as a massive cyber-espionage campaign against manufacturing and technology companies in North America and Asia that had been stealing immense stores of intellectual property and other sensitive data for years when it was discovered.

At that time, researchers estimated that Winnti — aka APT41, Wicked Panda, and Barium — so far had stolen hundreds of gigabytes of data, including trade secrets, blueprints, formulas, diagrams, and proprietary manufacturing documents, from more than 30 global organizations. They also harvested details about a target organization's network architecture, user accounts, credentials, customer data, and business units to leverage in future attacks.

The latest activity against Hong Kong organizations appears to be part of that broad campaign, which is likely to continue and ensnare more victims in its cyber-espionage web before it's over, researchers said. "The fact that this campaign has been ongoing for several years … indicates that the actors behind this activity are persistent and focused adversaries, with the ability to carry out stealthy operations on victim networks over a long period of time," they wrote.

**Unpacking a Trojan**

During the activity they observed Symantec researchers got a good look under the hood at Spyder Loader, which Winnti already had been spotted using as the initial payload in previous malicious activity.

Researchers at SonicWall were the first to discuss the malware publicly in March 2021, according to Symantec, which is part of Broadcom Software. At the time researchers identified the malware being used for targeted attacks on information storage systems to collect information about corrupted devices, execute mischievous payloads, coordinate script execution, and communicate with command and control systems, they said in their report.

The malware later was spotted being used in the Cuckoobees campaign and now again against Hong Kong organizations, with various variants being deployed this time around. All of them "displayed largely the same functionality" to load next-stage payloads and perform functions similar to those described by SonicWall, using obfuscation to hide malicious activity, the researchers said.

Winnti is believed to be working on behalf of, or with the support of, the Chinese government since at least 2010. Some security vendors have described Winnti as an umbrella group comprised of multiple threat actors operating under the control of China's state intelligence agencies.

In addition to Cuckoobees, Winnti also has been linked to attacks in 2010 on scores of US firms that included such heavy-hitters as Google and Yahoo. Its activity eventually led the US government to indict five members of the threat group, which in the end did little to stop its malicious activities.

**Technical Details**

Symantec researchers analyzed a sample of Spyder Loader compiled as a 64-bit PE DLL, a modified copy of sqlite3.dll with the addition of a malicious export, sqlite3\_prepare\_v4, which expects a string as its third argument, they said.

"Reportedly, whenever an export is executed by rundll32.exe, the third argument of the called export should contain part of the process command-line," researchers explained. "When this loader is executed, it extracts the file name from its third argument, and the referred file is expected to contain a sequence of records."

The malware executes a created wlbsctrl.dll file that likely acts as a next-stage loader that runs the content of a previously stored blob\_id 2 record — which it encrypts using the AES algorithm in Ciphertext Feedback (CFB) mode with segment\_size of 0x80 bits — from the created FileMapping, researchers explained. The encryption key is based on the name of an affected computer per GetComputerNameW() API, they said.

Spyder Loader also used other obfuscation techniques to prevent its activity from being analyzed, researchers said. In addition to AES encryption, the malware sample also used the ChaCha20 algorithm encryption to obfuscate one of the strings, as well as cleaned up created artifacts by overwriting the content of the dropped wlbsctrl.dll file before deleting it, for example, they said.

There are several similarities between the Spyder Loader activity seen in the Hong Kong campaign and its original functionality as described by Cybereason. They include: use of a modified version of sqlite3.dll; use of the third parameter of its malicious export that's consistent with the rundll32.exe command-line example seen in Cybereason’s research; and use of the CryptoPP C++ library.

In addition to Spyder Loader, credential-stealer Mimikatz and a Trojanized ZLib DLL were among the malware loaded onto victim machines, the researchers said.

The researchers included in their report a list of indicators of compromise for Spyder Loader in the post so enterprises can detect if their systems have been infected. They also encouraged organizations to stay up to date on the latest threats and malware in circulation that may require security updates by referring to Symantec's Protection Bulletins page.

China-Linked Cyber-Espionage Team Homes In on Hong Kong Government Orgs

An advanced persistent threat (APT) group of Chinese origin codenamed DiceyF has been linked to a string of attacks aimed at online casinos in Southeast Asia for years.
Russian cybersecurity company Kaspersky said the activity aligns with another set of intrusions attributed to Earth Berberoka (aka GamblingPuppet) and DRBControl, citing tactical and targeting similarities as well as the abuse of

An advanced persistent threat (APT) group of Chinese origin codenamed **DiceyF** has been linked to a string of attacks aimed at online casinos in Southeast Asia for years.

Russian cybersecurity company Kaspersky said the activity aligns with another set of intrusions attributed to Earth Berberoka (aka GamblingPuppet) and DRBControl, citing tactical and targeting similarities as well as the abuse of secure messaging clients.

"Possibly we have a mix of espionage and \[intellectual property\] theft, but the true motivations remain a mystery," researchers Kurt Baumgartner and Georgy Kucherin said in a technical write-up published this week.

The starting point of the investigation was in November 2021 when Kaspersky said it detected multiple PlugX loaders and other payloads that were deployed via an employee monitoring service and a security package deployment service.

The initial infection method – the distribution of the framework through security solution packages – afforded the threat actor "to perform cyberespionage activities with some level of stealth," the company stated.

Subsequently, the same security package deployment service is said to have been employed to deliver what's called the GamePlayerFramework, a C# variant of a C++-based malware known as PuppetLoader.

"This 'framework' includes downloaders, launchers, and a set of plugins that provide remote access and steal keystrokes and clipboard data," the researchers explained.

Indications are that the DiceyF activity is a follow-on campaign to Earth Berberoka with a retooled malware toolset, even as the framework is maintained through two separate branches dubbed Tifa and Yuna, which come with different modules of varying levels of sophistication.

While the Tifa branch contains a downloader and a core component, Yuna is more complex in terms of functionality, incorporating a downloader, a set of plugins, and at least 12 PuppetLoader modules. That said, both branches are believed to be actively and incrementally updated.

Regardless of the variant employed, the GamePlayerFramework, once launched, connects to a command-and-control (C2) and transmits information about the compromised host and the clipboard contents, after which the C2 responds with one of 15 commands that allow the malware to seize control of the machine.

This also includes launching a plugin on the victim system that can either be downloaded from the C2 server when the framework is instantiated or retrieved using the "InstallPlugin" command sent by the server.

These plugins, in turn, make it possible to steal cookies from Google Chrome and Mozilla Firefox browsers, capture keystroke and clipboard data, set up virtual desktop sessions, and even remotely connect to the machine over SSH.

Kaspersky also pointed to the use of a malicious app that mimics another software called Mango Employee Account Data Synchronizer, a messenger app used at the targeted entities, to drop the GamePlayerFramework within the network.

"There are many interesting characteristics of DiceyF campaigns and TTPs," the researchers said. "The group modifies their codebase over time, and develops functionality in the code throughout their intrusions."

"To make sure that victims did not become suspicious of the disguised implants, attackers obtained information about targeted organizations (such as the floor where the organization's IT department is located) and included it inside graphic windows displayed to victims."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Tag

#c++