GPAC 2.1-DEV-rev368-gfd054169b-master was discovered to contain a segmentation violation via the function gf_isom_get_meta_item_info at /isomedia/meta.c.

**Description**

SEGV in isomedia/meta.c:177 in gf\_isom\_get\_meta\_item\_info

**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 -info mp4box-info-segv-1
    

**POC**

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

**ASAN**

    [iso file] Unknown box type i000000 in parent iinf
    [iso file] Unknown top-level box type v000000
    [iso file] Incomplete box v000000 - start 308 size 191662031
    [iso file] Incomplete file while reading for dump - aborting parsing
    # File Meta type: "Meta" - 3 resource item(s)
    ASAN:DEADLYSIGNAL
    =================================================================
    ==52314==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x7f4d67b428f9 bp 0x000000000000 sp 0x7ffcd749c3c0 T0)
    ==52314==The signal is caused by a READ memory access.
    ==52314==Hint: address points to the zero page.
        #0 0x7f4d67b428f8 in gf_isom_get_meta_item_info isomedia/meta.c:177
        #1 0x55fa2660a89e in DumpMetaItem /gpac/applications/mp4box/filedump.c:2467
        #2 0x55fa26642cc8 in DumpMovieInfo /gpac/applications/mp4box/filedump.c:3820
        #3 0x55fa265efee4 in mp4box_main /gpac/applications/mp4box/mp4box.c:6359
        #4 0x7f4d669cfc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #5 0x55fa265c00a9 in _start (/gpac/bin/gcc/MP4Box+0x4e0a9)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV isomedia/meta.c:177 in gf_isom_get_meta_item_info
    ==52314==ABORTING
    

**Environment**

    Ubuntu 16.04
    Clang 10.0.1
    gcc 5.5

CVE-2022-43044: SEGV isomedia/meta.c:177 in gf_isom_get_meta_item_info · Issue #2282 · gpac/gpac

GPAC 2.1-DEV-rev368-gfd054169b-master was discovered to contain a segmentation violation via the function gf_isom_meta_restore_items_ref at /isomedia/meta.c.

**Description**

SEGV in isomedia/meta.c:1929 in gf\_isom\_meta\_restore\_items\_ref

**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 -info mp4box-info-segv-0
    

**POC**

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

**ASAN**

    [iso file] Read Box type 0003E8d (0x0003E864) at position 653 has size 0 but is not at root/file level. Forbidden, skipping end of parent box !
    [iso file] Missing DataInformationBox
    [iso file] Box "minf" (start 645) has 3400 extra bytes
    [iso file] Track with no sample table !
    [iso file] Track with no sample description box !
    [isom] not enough bytes in box A9too: 29 left, reading 41 (file isomedia/box_code_apple.c, line 117)
    [iso file] Read Box "A9too" (start 4122) failed (Invalid IsoMedia File) - skipping
    [iso file] Read Box "ilst" (start 4114) failed (Invalid IsoMedia File) - skipping
    [iso file] Read Box type 000000! (0x00000021) at position 4077 has size 0 but is not at root/file level. Forbidden, skipping end of parent box !
    [iso file] Box "meta" (start 4069) has 74 extra bytes
    ASAN:DEADLYSIGNAL
    =================================================================
    ==57686==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000002c (pc 0x7fb4c621a438 bp 0x000000000000 sp 0x7fff370fe330 T0)
    ==57686==The signal is caused by a READ memory access.
    ==57686==Hint: address points to the zero page.
        #0 0x7fb4c621a437 in gf_isom_meta_restore_items_ref isomedia/meta.c:1929
        #1 0x7fb4c60c4127 in gf_isom_parse_movie_boxes_internal isomedia/isom_intern.c:429
        #2 0x7fb4c60d00e5 in gf_isom_parse_movie_boxes isomedia/isom_intern.c:866
        #3 0x7fb4c60d00e5 in gf_isom_open_file isomedia/isom_intern.c:986
        #4 0x5627a34e0048 in mp4box_main /gpac/applications/mp4box/mp4box.c:6175
        #5 0x7fb4c5089c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #6 0x5627a34b30a9 in _start (/gpac/bin/gcc/MP4Box+0x4e0a9)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV isomedia/meta.c:1929 in gf_isom_meta_restore_items_ref
    ==57686==ABORTING
    

**Environment**

    Ubuntu 16.04
    Clang 10.0.1
    gcc 5.5

CVE-2022-43039: SEGV isomedia/meta.c:1929 in gf_isom_meta_restore_items_ref · Issue #2281 · gpac/gpac

GPAC 2.1-DEV-rev368-gfd054169b-master was discovered to contain a heap buffer overflow via the function FixSDTPInTRAF at isomedia/isom_intern.c.

**Description**

Heap-buffer-overflow in isomedia/isom\_intern.c:227 in FixSDTPInTRAF

**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-heap-buffer-over-flow-0
    

**POC**

https://github.com/17ssDP/fuzzer\_crashes/blob/main/gpac/mp4box-bt-heap-buffer-over-flow-0

**ASAN**

    [iso file] Unknown box type sjhm in parent sinf
    [iso file] Unknown box type sgp00 in parent stbl
    [iso file] Read Box type 00000000 (0x00000000) at position 2168 has size 0 but is not at root/file level. Forbidden, skipping end of parent box !
    [iso file] Box "traf" (start 2028) has 458 extra bytes
    [iso file] Unknown box type shgp in parent traf
    =================================================================
    ==31145==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000001914 at pc 0x7fe0339cbbf8 bp 0x7ffc2041a330 sp 0x7ffc2041a320
    READ of size 1 at 0x602000001914 thread T0
        #0 0x7fe0339cbbf7 in FixSDTPInTRAF isomedia/isom_intern.c:227
        #1 0x7fe0339cbbf7 in gf_isom_parse_movie_boxes_internal isomedia/isom_intern.c:663
        #2 0x7fe0339ce0e5 in gf_isom_parse_movie_boxes isomedia/isom_intern.c:866
        #3 0x7fe0339ce0e5 in gf_isom_open_file isomedia/isom_intern.c:986
        #4 0x55ec82396048 in mp4box_main /home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/applications/mp4box/mp4box.c:6175
        #5 0x7fe032987c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #6 0x55ec823690a9 in _start (/home/fuzz/dp/chunkfuzzer-evaluation/benchmark/gpac-asan/bin/gcc/MP4Box+0x4e0a9)
    
    0x602000001914 is located 0 bytes to the right of 4-byte region [0x602000001910,0x602000001914)
    allocated by thread T0 here:
        #0 0x7fe035ef3b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
        #1 0x7fe0338a4541 in sdtp_box_read isomedia/box_code_base.c:8354
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow isomedia/isom_intern.c:227 in FixSDTPInTRAF
    Shadow bytes around the buggy address:
      0x0c047fff82d0: fa fa 00 00 fa fa 00 00 fa fa 01 fa fa fa 00 00
      0x0c047fff82e0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fa
      0x0c047fff82f0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
      0x0c047fff8300: fa fa 00 fa fa fa 00 00 fa fa 00 07 fa fa 00 00
      0x0c047fff8310: fa fa 00 fa fa fa 00 00 fa fa 00 00 fa fa 00 00
    =>0x0c047fff8320: fa fa[04]fa fa fa 00 00 fa fa 00 00 fa fa fa fa
      0x0c047fff8330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8370: 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
    ==31145==ABORTING
    

**Environment**

    Ubuntu 16.04
    Clang 10.0.1
    gcc 5.5

CVE-2022-43042: heap-buffer-overflow isomedia/isom_intern.c:227 in FixSDTPInTRAF · Issue #2278 · gpac/gpac

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 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 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

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

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.

Tag

#c++