Bento4 v1.6.0-639 was discovered to contain a memory leak in the AP4_AvcFrameParser::Feed function in mp4mux.

**Summary**

Hi there,  
These are some faults that maybe lead to serious consequences in mp4xx, the version of Bento4 is the latest (the newest master branch) and the operation system is Ubuntu 18.04.6 LTS (docker), these binary-crashes with the following.

**Bug1**

Detected memory leaks in mp4spilt:

    root@32345fj4sds:/fuzz-mp4split/mp4split# ./mp4split --video ../out/crashes/poc_split_1
    --video option specified, but no video track found
    
    =================================================================
    ==1889275==ERROR: LeakSanitizer: detected memory leaks
    
    Indirect leak of 592 byte(s) in 2 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x462e2f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462e2f)
        #3 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #4 0x490c11 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x490c11)
    
    Indirect leak of 256 byte(s) in 1 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x45904a in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x45904a)
        #3 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #4 0x46094f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x46094f)
        #5 0x4c4b30 in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c4b30)
        #6 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #7 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #8 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 224 byte(s) in 7 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #3 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #4 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 192 byte(s) in 2 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #3 0x46094f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x46094f)
        #4 0x4c4b30 in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c4b30)
        #5 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #6 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #7 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 176 byte(s) in 2 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x46094f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x46094f)
        #3 0x4c4b30 in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c4b30)
        #4 0x4c6558 in AP4_File::AP4_File(AP4_ByteStream&, bool) (/fuzz-mp4split/mp4split/mp4split+0x4c6558)
        #5 0x40abba in main (/fuzz-mp4split/mp4split/mp4split+0x40abba)
        #6 0x7f88d878dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
                                                                                                   …… ……
    
    Indirect leak of 24 byte(s) in 1 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x4bdd4d in AP4_ElstAtom::Create(unsigned int, AP4_ByteStream&) (/fuzz-mp4split/mp4split/mp4split+0x4bdd4d)
        #3 0x45831c in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x45831c)
        #4 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #5 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #6 0x48e726 in AP4_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x48e726)
        #7 0x45dc8c in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x45dc8c)
        #8 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #9 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #10 0x490c11 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x490c11)
    
    Indirect leak of 1 byte(s) in 1 object(s) allocated from:
        #0 0x8c7670 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7f88d8e08297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x771319 in AP4_DescriptorFactory::CreateDescriptorFromStream(AP4_ByteStream&, AP4_Descriptor*&) (/fuzz-mp4split/mp4split/mp4split+0x771319)
        #3 0x539cf7 in AP4_InitialObjectDescriptor::AP4_InitialObjectDescriptor(AP4_ByteStream&, unsigned char, unsigned int, unsigned int) (/fuzz-mp4split/mp4split/mp4split+0x539cf7)
        #4 0x7713f7 in AP4_DescriptorFactory::CreateDescriptorFromStream(AP4_ByteStream&, AP4_Descriptor*&) (/fuzz-mp4split/mp4split/mp4split+0x7713f7)
        #5 0x4e9d46 in AP4_IodsAtom::Create(unsigned int, AP4_ByteStream&) (/fuzz-mp4split/mp4split/mp4split+0x4e9d46)
        #6 0x4558fa in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x4558fa)
        #7 0x462a0f in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) (/fuzz-mp4split/mp4split/mp4split+0x462a0f)
        #8 0x48ef27 in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) (/fuzz-mp4split/mp4split/mp4split+0x48ef27)
        #9 0x490c11 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) (/fuzz-mp4split/mp4split/mp4split+0x490c11)
    
    SUMMARY: AddressSanitizer: 2750 byte(s) leaked in 39 allocation(s).
    
    

**Bug2**

SEGV on unknown address 0x000000000028 in mp4decrypt:

    root@23435332df4:/fuzz-mp4decrypt/mp4decrypt# ./mp4decrypt ../out/crashes/poc_decrypt_1 /dev/null
    WARNING: atom serialized to fewer bytes than declared size
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2367709==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x0000005da294 bp 0x7ffcee6b84c0 sp 0x7ffcee6b6b60 T0)
    ==2367709==The signal is caused by a READ memory access.
    ==2367709==Hint: address points to the zero page.
        #0 0x5da294 in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&) (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x5da294)
        #1 0x5f795d in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x5f795d)
        #2 0x414e8b in main (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x414e8b)
        #3 0x7fdba0338c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #4 0x407b69 in _start (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x407b69)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/fuzz-mp4decrypt/mp4decrypt/mp4decrypt+0x5da294) in AP4_Processor::ProcessFragments(AP4_MoovAtom*, AP4_List<AP4_AtomLocator>&, AP4_ContainerAtom*, AP4_SidxAtom*, unsigned long long, AP4_ByteStream&, AP4_ByteStream&)
    ==2367709==ABORTING
    
    

**Bug3**

Detected memory leaks in mp4mux:

    root@wha446aq:/# ./Bento4/cmakebuild/mp4mux --track h264:poc_mp4mux_1 /dev/null
    ERROR: Feed() failed (-10)
    
    =================================================================
    ==17429==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 148 byte(s) in 1 object(s) allocated from:
        #0 0x4f5ce8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x52d6b2 in AP4_AvcFrameParser::Feed(unsigned char const*, unsigned int, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/Bento4/cmakebuild/mp4mux+0x52d6b2)
    
    SUMMARY: AddressSanitizer: 148 byte(s) leaked in 1 allocation(s).
    

**POC**

Bug\_1\_POC.zip  
Bug\_2\_POC.zip  
Bug\_3\_POC.zip

**Environment**

Ubuntu 18.04.6 LTS (docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25) && Bento4 release version(1.6.0-639)

**Credit**

Xudong Cao (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)  
Yuhang Huang (NCNIPC of China)  
Jiayuan Zhang (NCNIPC of China)

Thank you for your time!

CVE-2022-41427: Some vulnerabilities about mp4xx can cause serious errors · Issue #772 · axiomatic-systems/Bento4

Bento4 v1.6.0-639 was discovered to contain a memory leak via the AP4_SttsAtom::Create function in mp42hls.

CVE-2022-41424: Detected memory leaks in mp42hls · Issue #768 · axiomatic-systems/Bento4

Bento4 v1.6.0-639 was discovered to contain a segmentation violation in the mp4fragment component.

**Summary**

Hi there, I use my fuzzer for fuzzing the binary mp4fragment, the version of Bento4 is the latest (the newest master branch) and the operation system is Ubuntu 18.04.6 LTS (docker) and this binary crashes with the following.

**Details**

    root@4e3b7f9edc0d:/mp4box/mp4fragment# ./mp4fragment ../out/crashes/id\:000000\,sig\:06\,src\:000008\,op\:flip1\,pos\:31325\,4970731 /dev/null
    unable to autodetect fragment duration, using default
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==750986==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f5fc13c0306 bp 0x7ffe16f62f30 sp 0x7ffe16f626c8 T0)
    ==750986==The signal is caused by a READ memory access.
    ==750986==Hint: address points to the zero page.
        #0 0x7f5fc13c0306  (/lib/x86_64-linux-gnu/libc.so.6+0xb1306)
        #1 0x94da2c in __interceptor_strlen.part.36 /llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:370
        #2 0x6ec0c2 in AP4_TrakAtom::AP4_TrakAtom(AP4_SampleTable*, unsigned int, char const*, unsigned int, unsigned long long, unsigned long long, unsigned long long, unsigned int, unsigned long long, unsigned short, char const*, unsigned int, unsigned int, unsigned short, unsigned short, int const*) (/mp4box/mp4fragment/mp4fragment+0x6ec0c2)
        #3 0x432bbc in main (/mp4box/mp4fragment/mp4fragment+0x432bbc)
        #4 0x7f5fc1330c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #5 0x407cd9 in _start (/mp4box/mp4fragment/mp4fragment+0x407cd9)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0xb1306) 
    ==750986==ABORTING
    
    

**POC**

POC-Mp4fragment-1.zip

**Environment**

Ubuntu 18.04.6 LTS (docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25) && Bento4 release version(1.6.0-639)

**Credit**

Xudong Cao (NCNIPC of China)  
Jiayuan Zhang (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)

Thank you for your time!

CVE-2022-41423: From mp4fragment: SEGV on unknown address 0x000000000000 · Issue #767 · axiomatic-systems/Bento4

Bento4 v1.6.0-639 was discovered to contain a memory leak via the AP4_Processor::Process function in the mp4encrypt binary.

**Summary**

Hi, developers of Bento4:  
I tested the binary mp4encrypt with my fuzzer, and a crash incurred, i.e., memory leaks error. The version of Bento4 is the latest (the newest master branch) and the operation system is Ubuntu 18.04.6 LTS (docker). The following is the details.

**Details**

    root@c08635047aea:/fuzz-mp4encrypt/mp4encrypt# ./mp4encrypt --method MARLIN-IPMP-ACBC ../out/crashes/id\:000007\,sig\:06\,src\:000001\,op\:flip1\,pos\:14136\,934837 /dev/null
    WARNING: track ID 1 will not be encrypted
    WARNING: atom serialized to fewer bytes than declared size
    
    =================================================================
    ==3055140==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 104 byte(s) in 1 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #3 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #4 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 3328 byte(s) in 2 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x5b2921 in AP4_MarlinIpmpEncryptingProcessor::Initialize(AP4_AtomParent&, AP4_ByteStream&, AP4_Processor::ProgressListener*) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x5b2921)
        #3 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #4 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #5 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 1024 byte(s) in 1 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x8b62f9 in AP4_Expandable::Write(AP4_ByteStream&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x8b62f9)
        #3 0x5b2540 in AP4_MarlinIpmpEncryptingProcessor::Initialize(AP4_AtomParent&, AP4_ByteStream&, AP4_Processor::ProgressListener*) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x5b2540)
        #4 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #5 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #6 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 224 byte(s) in 5 object(s) allocated from:
        #0 0x9a1c90 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fda31f4c297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x64923f in AP4_Processor::Process(AP4_ByteStream&, AP4_ByteStream&, AP4_ByteStream*, AP4_Processor::ProgressListener*, AP4_AtomFactory&) (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x64923f)
        #3 0x42128c in main (/fuzz-mp4encrypt/mp4encrypt/mp4encrypt+0x42128c)
        #4 0x7fda31110c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    SUMMARY: AddressSanitizer: 4680 byte(s) leaked in 9 allocation(s).
    
    

**POC**

mp4encrypt\_poc1.zip

**Environment**

Ubuntu 18.04.6 LTS (docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25) && Bento4 release version(1.6.0-639)

**Credit**

Xudong Cao (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)

Thank you for your time!

CVE-2022-41419: Detected memory leaks in mp4encrypt · Issue #766 · axiomatic-systems/Bento4

An issue was discovered in Bento4 1.6.0-639. A memory leak exists in AP4_StdcFileByteStream::Create(AP4_FileByteStream*, char const*, AP4_FileByteStream::Mode, AP4_ByteStream*&) in System/StdC/Ap4StdCFileByteStream.cpp.

Hello, I use fuzer to test binary acc2mp4, and found some carshes, which can result binary mp4split crash too. Here are the details.

**Bug1**

    root@d5f4647d38bd:/aac2mp4/aac2mp4# /Bento4/build/aac2mp4 crash1 /dev/null
    AAC frame [000000]: size = -7, 96000 kHz, 0 ch
    =================================================================
    ==813117==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62d000008400 at pc 0x0000004ad912 bp 0x7ffe2c57b390 sp 0x7ffe2c57ab40
    READ of size 4294967287 at 0x62d000008400 thread T0
        #0 0x4ad911 in __asan_memcpy /llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22
        #1 0x4facae in AP4_BitStream::ReadBytes(unsigned char*, unsigned int) /Bento4/Source/C++/Codecs/Ap4BitStream.cpp:192:10
        #2 0x4f8485 in main /Bento4/Source/C++/Apps/Aac2Mp4/Aac2Mp4.cpp:142:29
        #3 0x7fec98881c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #4 0x41c349 in _start (/Bento4/build/aac2mp4+0x41c349)
    
    0x62d000008400 is located 0 bytes to the right of 32768-byte region [0x62d000000400,0x62d000008400)
    allocated by thread T0 here:
        #0 0x4f4638 in operator new[](unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:102
        #1 0x4fa30d in AP4_BitStream::AP4_BitStream() /Bento4/Source/C++/Codecs/Ap4BitStream.cpp:45:16
        #2 0x7fec98881c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22 in __asan_memcpy
    Shadow bytes around the buggy address:
      0x0c5a7fff9030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fff9040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fff9050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fff9060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fff9070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c5a7fff9080:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fff9090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fff90a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fff90b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fff90c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fff90d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==813117==ABORTING
    
    

**Bug2**

    root@d5f4647d38bd:/aac2mp4/aac2mp4# ./mp4split crash2
    no movie found in file
    
    =================================================================
    ==888268==ERROR: LeakSanitizer: detected memory leaks
    
    Direct leak of 48 byte(s) in 1 object(s) allocated from:
        #0 0x4f45d8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x5de94f in AP4_StdcFileByteStream::Create(AP4_FileByteStream*, char const*, AP4_FileByteStream::Mode, AP4_ByteStream*&) /Bento4/Source/C++/System/StdC/Ap4StdCFileByteStream.cpp:279:14
    
    Indirect leak of 256 byte(s) in 1 object(s) allocated from:
        #0 0x4f45d8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x536495 in AP4_Array<unsigned int>::EnsureCapacity(unsigned int) /Bento4/Source/C++/Core/Ap4Array.h:172:25
        #2 0x536495 in AP4_Array<unsigned int>::Append(unsigned int const&) /Bento4/Source/C++/Core/Ap4Array.h:252:29
        #3 0x536495 in AP4_FtypAtom::AP4_FtypAtom(unsigned int, AP4_ByteStream&) /Bento4/Source/C++/Core/Ap4FtypAtom.cpp:57:28
        #4 0x50966b in AP4_FtypAtom::Create(unsigned int, AP4_ByteStream&) /Bento4/Source/C++/Core/Ap4FtypAtom.h:66:20
        #5 0x50966b in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:630:20
        #6 0x507ec4 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234:14
        #7 0x5076ee in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:154:12
        #8 0x5350be in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) /Bento4/Source/C++/Core/Ap4File.cpp:104:12
        #9 0x5357ed in AP4_File::AP4_File(AP4_ByteStream&, bool) /Bento4/Source/C++/Core/Ap4File.cpp:78:5
        #10 0x4f841f in main /Bento4/Source/C++/Apps/Mp4Split/Mp4Split.cpp:258:26
        #11 0x7f11ba50dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 88 byte(s) in 1 object(s) allocated from:
        #0 0x4f45d8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x507f57 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:242:16
        #2 0x5076ee in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:154:12
        #3 0x5350be in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) /Bento4/Source/C++/Core/Ap4File.cpp:104:12
        #4 0x5357ed in AP4_File::AP4_File(AP4_ByteStream&, bool) /Bento4/Source/C++/Core/Ap4File.cpp:78:5
        #5 0x4f841f in main /Bento4/Source/C++/Apps/Mp4Split/Mp4Split.cpp:258:26
        #6 0x7f11ba50dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 72 byte(s) in 1 object(s) allocated from:
        #0 0x4f45d8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x4f83f7 in main /Bento4/Source/C++/Apps/Mp4Split/Mp4Split.cpp:258:22
        #2 0x7f11ba50dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 72 byte(s) in 1 object(s) allocated from:
        #0 0x4f45d8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x509659 in AP4_FtypAtom::Create(unsigned int, AP4_ByteStream&) /Bento4/Source/C++/Core/Ap4FtypAtom.h:66:16
        #2 0x509659 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:630:20
        #3 0x507ec4 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:234:14
        #4 0x5076ee in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, AP4_Atom*&) /Bento4/Source/C++/Core/Ap4AtomFactory.cpp:154:12
        #5 0x5350be in AP4_File::ParseStream(AP4_ByteStream&, AP4_AtomFactory&, bool) /Bento4/Source/C++/Core/Ap4File.cpp:104:12
        #6 0x5357ed in AP4_File::AP4_File(AP4_ByteStream&, bool) /Bento4/Source/C++/Core/Ap4File.cpp:78:5
        #7 0x4f841f in main /Bento4/Source/C++/Apps/Mp4Split/Mp4Split.cpp:258:26
        #8 0x7f11ba50dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    Indirect leak of 48 byte(s) in 2 object(s) allocated from:
        #0 0x4f45d8 in operator new(unsigned long) /llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:99
        #1 0x4fd2d3 in AP4_List<AP4_Atom>::Add(AP4_Atom*) /Bento4/Source/C++/Core/Ap4List.h:160:16
        #2 0x4fd2d3 in AP4_AtomParent::AddChild(AP4_Atom*, int) /Bento4/Source/C++/Core/Ap4Atom.cpp:532:29
    
    SUMMARY: AddressSanitizer: 584 byte(s) leaked in 7 allocation(s).
    

**Environment**

Ubuntu 18.04(docker)  
clang 12.0.1  
clang++ 12.0.1  
Bento4 master branch(5b7cc25)

**How to reproduce**

    export CC=clang
    export CXX=clang++
    export CFLAGS="-fsanitize=address -g"
    export CXXFLAGS="-fsanitize=address -g"
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Release ..
    make
    
    

**POC**

crash.zip

**Credit**

Yuhang Huang (NCNIPC of China)  
Han Zheng (NCNIPC of China, Hexhive)  
Yin li,Jiayu Zhao(NCNIPC of China)

**Notice**

I find the two bugs not only exist in latest branch but also exist in latest release version Bento4-1.6.0-639.  
The bug1 is similar to the issuse#363(CVE-2019-8378),which means this bug hasn't been fixed now.

Thanks for your time!

CVE-2022-41847: there are some bugs in Bento4 · Issue #775 · axiomatic-systems/Bento4

There is a use-after-free issue in JBIG2Stream::close() located in JBIG2Stream.cc in Xpdf 4.04. It can be triggered by sending a crafted PDF file to (for example) the pdfimages binary. It allows an attacker to cause Denial of Service or possibly have unspecified other impact.

Hello, I was testing my fuzzer and found a use-after-free in xpdf-4.04, can be triggered via a crafted pdf file.

\## Environment  
Ubuntu 22.04 (docker)  
gcc-11.2.0  
xpdf-4.04

\## step to reporduce  
\`\`\`  
cd $PATH\_TO\_XPDF && mkdir build && pushd build  
cmake -DCMAKE\_BUILD\_TYPE=Release -DCMAKE\_C\_FLAGS="-fsanitize=address -g" -DCMAKE\_CXX\_FLAGS="-fsanitize=address -g" ../  
./xpdf/pdfimages $POC /dev/null  
\`\`\`  
\## ASan Log  
\`\`\`  
\=================================================================  
\==1164636==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000012970 at pc 0x55c1c290fa1a bp 0x7ffc26bd4430 sp 0x7ffc26bd4420  
READ of size 8 at 0x603000012970 thread T0  
#0 0x55c1c290fa19 in JBIG2Stream::close() /validate/xpdf/xpdf-4.04/xpdf/JBIG2Stream.cc:1216  
#1 0x55c1c290fa84 in JBIG2Stream::~JBIG2Stream() /validate/xpdf/xpdf-4.04/xpdf/JBIG2Stream.cc:1180  
#2 0x55c1c290ffdc in JBIG2Stream::~JBIG2Stream() /validate/xpdf/xpdf-4.04/xpdf/JBIG2Stream.cc:1202  
#3 0x55c1c293642a in Object::free() /validate/xpdf/xpdf-4.04/xpdf/Object.cc:138  
#4 0x55c1c280217d in Gfx::opXObject(Object\*, int) /validate/xpdf/xpdf-4.04/xpdf/Gfx.cc:4136  
#5 0x55c1c2868ab3 in Gfx::execOp(Object\*, Object\*, int) /validate/xpdf/xpdf-4.04/xpdf/Gfx.cc:862  
#6 0x55c1c2868f88 in Gfx::go(int) /validate/xpdf/xpdf-4.04/xpdf/Gfx.cc:747  
#7 0x55c1c28695a6 in Gfx::display(Object\*, int) /validate/xpdf/xpdf-4.04/xpdf/Gfx.cc:669  
#8 0x55c1c2943025 in Page::displaySlice(OutputDev\*, double, double, int, int, int, int, int, int, int, int, int (\*)(void\*), void\*) /validate/xpdf/xpdf-4.04/xpdf/Page.cc:422  
#9 0x55c1c2943882 in Page::display(OutputDev\*, double, double, int, int, int, int, int (\*)(void\*), void\*) /validate/xpdf/xpdf-4.04/xpdf/Page.cc:368  
#10 0x55c1c294d4a3 in PDFDoc::displayPages(OutputDev\*, int, int, double, double, int, int, int, int, int (\*)(void\*), void\*) /validate/xpdf/xpdf-4.04/xpdf/PDFDoc.cc:460  
#11 0x55c1c280656d in main /validate/xpdf/xpdf-4.04/xpdf/pdfimages.cc:156  
#12 0x7efd8b7e7d8f in \_\_libc\_start\_call\_main ../sysdeps/nptl/libc\_start\_call\_main.h:58  
#13 0x7efd8b7e7e3f in \_\_libc\_start\_main\_impl ../csu/libc-start.c:392  
#14 0x55c1c28070b4 in \_start (/validate/xpdf/xpdf-4.04/build/xpdf/pdfimages+0x1280b4)

0x603000012970 is located 0 bytes inside of 32-byte region \[0x603000012970,0x603000012990)  
freed by thread T0 here:  
#0 0x7efd8bdd022f in operator delete(void\*, unsigned long) ../../../../src/libsanitizer/asan/asan\_new\_delete.cpp:172  
#1 0x55c1c290b19f in JBIG2Bitmap::~JBIG2Bitmap() /validate/xpdf/xpdf-4.04/xpdf/JBIG2Stream.cc:740  
#2 0x55c1c290b19f in JBIG2Stream::readPageInfoSeg(unsigned int) /validate/xpdf/xpdf-4.04/xpdf/JBIG2Stream.cc:3960

previously allocated by thread T0 here:  
#0 0x7efd8bdcf1c7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan\_new\_delete.cpp:99  
#1 0x55c1c290b1fd in JBIG2Stream::readPageInfoSeg(unsigned int) /validate/xpdf/xpdf-4.04/xpdf/JBIG2Stream.cc:3969

SUMMARY: AddressSanitizer: heap-use-after-free /validate/xpdf/xpdf-4.04/xpdf/JBIG2Stream.cc:1216 in JBIG2Stream::close()  
Shadow bytes around the buggy address:  
0x0c067fffa4d0: fd fd fa fa fd fd fd fa fa fa 00 00 01 fa fa fa  
0x0c067fffa4e0: 00 00 00 00 fa fa 00 00 00 00 fa fa fd fd fd fd  
0x0c067fffa4f0: fa fa fd fd fd fd fa fa fd fd fd fa fa fa 00 00  
0x0c067fffa500: 01 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa  
0x0c067fffa510: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00  
\=>0x0c067fffa520: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa\[fd\]fd  
0x0c067fffa530: fd fd fa fa fd fd fd fd fa fa fa fa fa fa fa fa  
0x0c067fffa540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fffa550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fffa560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c067fffa570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
Left alloca redzone: ca  
Right alloca redzone: cb  
Shadow gap: cc  
\==1164636==ABORTING  
\`\`\`  
\## Credit  
Han Zheng, NCNIPC of China, Hexhive

\## POC

CVE-2022-38222: [BUG] use-after-free in pdfimages,xpdf-4.04 - forum.xpdfreader.com

Cloud-native threats are costing cloud customer victims money as cryptojackers mine their vulnerable cloud instances.

Threats against cloud-native infrastructure are on the rise, particularly as attackers target cloud and container resources to power their illicit cryptomining operations. In the latest twist, cybercriminals are wreaking havoc on cloud resources to both propagate and run cryptojacking enterprises in costly schemes that cost victims some $50 in cloud resources for every $1 worth of cryptocurrency that the crooks mine off of these compute reserves.

That's according to a new report out today from Sysdig, which shows that while the bad guys will indiscriminately attack any weak cloud or container resources they can get their hands on to power money-making cryptomining schemes, they're also cleverly strategic about it. 

In fact, many of the most crafty software supply chain attacks are in large part designed to spawn cryptominers via infected container images. Attackers not only leverage source code dependencies most commonly thought of in offensive supply chain attacks — they also leverage malicious container images as an effective attack vehicle, according to Sysdig's "2022 Cloud-Native Threat Report." 

Cybercriminals are taking advantage of the trend within the development community to share code and open source projects via premade container images via container registries like Docker Hub. Container images have all the required software installed and configured in an easy-to-deploy workload. While that's a serious time saver for developers, it also opens up a path for attackers to create images that have malicious payloads built in and then to seed platforms like DockerHub with their malicious wares. All it takes is for a developer to run a Docker pull request from the platform to get that malicious image running. What's more, the Docker Hub download and installation is opaque, making it even harder to spot the potential for trouble.

"It’s clear that container images have become a real attack vector, rather than a theoretical risk," the report explained, for which the Sysdig Threat Research Team (TRT) went through a monthslong process of sifting through public container images uploaded by users worldwide onto DockerHub to find malicious instances. "The methods employed by malicious actors described by Sysdig TRT are specifically targeted at cloud and container workloads."

The team's hunt surfaced more than 1,600 malicious images containing cryptominers, backdoors, and other nasty malware disguised as legitimate popular software. Cryptominers were far and away the most prevalent, making up 36% of the samples.

"Security teams can no longer delude themselves with the idea that 'containers are too new or too ephemeral for threat actors to bother,'" says Stefano Chierici, senior security researcher at Sysdig and co-author of the report. "Attackers are in the cloud, and they are taking real money. The high prevalence of cryptojacking activity is attributable to the low risk and high reward for the perpetrators."

**TeamTNT and Chimera**

As a part of the report, Chierici and his colleagues also did a deep-dive technical analysis of the tactics, techniques, and procedures (TTPs) of the TeamTNT threat group. Active since 2019, the group according to some sources has compromised over 10,000 cloud and container devices during one of its most prevalent attack campaigns, Chimera. It's best known for cryptojacking worm activity and according to the report, TeamTNT continues to refine its scripts and its TTPs in 2022. For example, it now connects scripts with the AWS Cloud Metadata service to leverage credentials associated with an EC2 instance and gain access to other resources tied to a compromised instance.

"If there are excessive permissions associated with these credentials, the attacker could gain even more access. Sysdig TRT believes that TeamTNT would want to leverage these credentials, if capable, to create more EC2 instances so it could increase its cryptomining capabilities and profits," the report said.

As part of its analysis, the team dug into a a number of XMR wallets used by TeamTNT during mining campaigns to figure out the financial impact of cryptojacking. 

Utilizing technical analysis of the threat group's operational practices during the Chimera operation, Sysdig was able to find that the adversary cost its victims $11,000 on a single AWS EC2 instance for every XMR it mined. The wallets the team recovered amounted some 40 XMR, meaning that the attackers drove up a cloud bill of nearly $430,000 to mine those coins. 

Using coin valuation from earlier this year, the report estimated the value of those coins equals about $8,100, with back-of-envelope figuring then showing that for every dollar the bad guys make, they cost victims at least $53 in cloud bills alone.

Container Supply Chain Attacks Cash In on Cryptojacking

A new, multi-functional Go-based malware dubbed Chaos has been rapidly growing in volume in recent months to ensnare a wide range of Windows, Linux, small office/home office (SOHO) routers, and enterprise servers into its botnet.
"Chaos functionality includes the ability to enumerate the host environment, run remote shell commands, load additional modules, automatically propagate through

A new, multi-functional Go-based malware dubbed **Chaos** has been rapidly growing in volume in recent months to ensnare a wide range of Windows, Linux, small office/home office (SOHO) routers, and enterprise servers into its botnet.

"Chaos functionality includes the ability to enumerate the host environment, run remote shell commands, load additional modules, automatically propagate through stealing and brute-forcing SSH private keys, as well as launch DDoS attacks," researchers from Lumen's Black Lotus Labs said in a write-up shared with The Hacker News.

A majority of the bots are located in Europe, specifically Italy, with other infections reported in China and the U.S., collectively representing "hundreds of unique IP addresses" over a one-month time period from mid-June through mid-July 2022.

Written in Chinese and leveraging China-based infrastructure for command-and-control, the botnet joins a long list of malware that are designed to establish persistence for extended periods and likely abuse the foothold for nefarious purposes, such as DDoS attacks and cryptocurrency mining.

If anything, the development also points to a dramatic uptick in threat actors shifting to programming languages like Go to evade detection and render reverse engineering difficult, not to mention targeting several platforms at once.

Chaos (not to be confused with the ransomware builder of the same name) lives up to its name by exploiting known security vulnerabilities to gain initial access, subsequently abusing it to conduct reconnaissance and initiate lateral movement across the compromised network.

What's more, the malware has versatility that similar malware does not, enabling it to operate across a wide range of instruction set architectures from ARM, Intel (i386), MIPS, and PowerPC, effectively allowing the threat actor to broaden the scope of its targets and swiftly accrue in volume.

On top of that, Chaos further has the ability to execute as many as 70 different commands sent from the C2 server, one of which is an instruction to trigger the exploitation of publicly-disclosed flaws (CVE-2017-17215 and CVE-2022-30525) defined in a file.

Chaos is also believed to be an evolution of another Go-based DDoS malware named Kaiji that has previously targeted misconfigured Docker instances. The correlations, per Black Lotus Labs, stem from overlapping code and functions based on an analysis of over 100 samples.

A GitLab server located in Europe was one among the victims of the Chaos botnet in the first weeks of September, the company said, adding it identified a string of DDoS attacks aimed at entities spanning gaming, financial services, and technology, media and entertainment, and hosting providers. Also targeted was a crypto mining exchange.

The findings come exactly three months after the cybersecurity company exposed a new remote access trojan dubbed ZuoRAT that has been singling out SOHO routers as part of a sophisticated campaign directed against North American and European networks.

"We are seeing a complex malware that has quadrupled in size in just two months, and it is well-positioned to continue accelerating," said Mark Dehus, director of threat intelligence for Lumen Black Lotus Labs. "Chaos poses a threat to a variety of consumer and enterprise devices and hosts."

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

Researchers Warn of New Go-based Malware Targeting Windows and Linux Systems

Red Hat Security Advisory 2022-6714-01 - Updated images are now available for Red Hat Advanced Cluster Security for Kubernetes (RHACS). The updated image includes new features and bug fixes.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Moderate: RHACS 3.72 enhancement and security update  
Advisory ID:       RHSA-2022:6714-01  
Product:           RHACS  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:6714  
Issue date:        2022-09-26  
CVE Names:         CVE-2015-20107 CVE-2022-0391 CVE-2022-1292   
                   CVE-2022-1586 CVE-2022-1785 CVE-2022-1897   
                   CVE-2022-1927 CVE-2022-2068 CVE-2022-2097   
                   CVE-2022-24675 CVE-2022-24921 CVE-2022-28327   
                   CVE-2022-29154 CVE-2022-29526 CVE-2022-30631   
                   CVE-2022-32206 CVE-2022-32208 CVE-2022-34903   
=====================================================================

1. Summary:

Updated images are now available for Red Hat Advanced Cluster Security for  
Kubernetes (RHACS). The updated image includes new features and bug fixes.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Description:

Release of RHACS 3.72 provides these changes:

New features  
* Automatic removal of nonactive clusters from RHACS: RHACS provides the  
ability to configure your system to automatically remove nonactive clusters  
from RHACS so that you can monitor active clusters only.  
* Support for unauthenticated email integration: RHACS now supports  
unauthenticated SMTP for email integrations. This is insecure and not  
recommended.  
* Support for Quay robot accounts: RHACS now supports use of robot accounts  
in quay.io integrations. You can create robot accounts in Quay that allow  
you to share credentials for use in multiple repositories.  
* Ability to view Dockerfile lines in images that introduced components  
with Common Vulnerabilities and Exposures (CVEs): In the Images view, under  
Image Findings, you can view individual lines in the Dockerfile that  
introduced the components that have been identified as containing CVEs.  
* Network graph improvements: RHACS 3.72 includes some improvements to the  
Network Graph user interface.

Known issue  
* RHACS shows the wrong severity when two severities exist for a single  
vulnerability in a single distribution. This issue occurs because RHACS  
scopes severities by namespace rather than component. There is no  
workaround. It is anticipated that an upcoming release will include a fix  
for this issue. (ROX-12527)

Bug fixes  
* Before this update, the steps to configure OpenShift Container Platform  
OAuth for more than one URI were missing. The documentation has been  
revised to include instructions for configuring OAuth in OpenShift  
Container Platform to use more than one URI. For more information, see  
Creating additional routes for the OpenShift Container Platform OAuth  
server. (ROX-11296)  
* Before this update, the autogenerated image integration, such as a Docker  
registry integration, for a cluster is not deleted when the cluster is  
removed from Central. This issue is fixed. (ROX-9398)  
* Before this update, the Image OS policy criteria did not support regular  
expressions, or regex. However, the documentation indicated that regular  
expressions were supported. This issue is fixed by adding support for  
regular expressions for the Image OS policy criteria. (ROX-12301)  
* Before this update, the syslog integration did not respect a configured  
TCP proxy. This is now fixed.  
* Before this update, the scanner-db pod failed to start when a resource  
quota was set for the stackrox namespace, because the init-db container in  
the pod did not have any resources assigned to it. The init-db container  
for ScannerDB now specifies resource requests and limits that match the db  
container. (ROX-12291)

Notable technical changes  
* Scanning support for Red Hat Enterprise Linux 9: RHEL 9 is now generally  
available (GA). RHACS 3.72 introduces support for analyzing images built  
with Red Hat Universal Base Image (UBI) 9 and Red Hat Enterprise Linux  
(RHEL) 9 RPMs for vulnerabilities.  
* Policy for CVEs with fixable CVSS of 6 or greater disabled by default:  
Beginning with this release, the Fixable CVSS >= 6 and Privileged policy is  
no longer enabled by default for new RHACS installations. The configuration  
of this policy is not changed when upgrading an existing system. A new  
policy Privileged Containers with Important and Critical Fixable CVEs,  
which gives an alert for containers running in privileged mode that have  
important or critical fixable vulnerabilities, has been added.

Security Fix(es)  
* golang: encoding/pem: fix stack overflow in Decode (CVE-2022-24675)  
* golang: regexp: stack exhaustion via a deeply nested expression  
(CVE-2022-24921)  
* golang: crypto/elliptic: panic caused by oversized scalar  
(CVE-2022-28327)  
* golang: syscall: faccessat checks wrong group (CVE-2022-29526)  
* golang: compress/gzip: stack exhaustion in Reader.Read (CVE-2022-30631)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

3. Solution:

To take advantage of the new features, bug fixes, and enhancements in RHACS  
3.72 you are advised to upgrade to RHACS 3.72.0.

4. Bugs fixed (https://bugzilla.redhat.com/):

2064857 - CVE-2022-24921 golang: regexp: stack exhaustion via a deeply nested expression  
2077688 - CVE-2022-24675 golang: encoding/pem: fix stack overflow in Decode  
2077689 - CVE-2022-28327 golang: crypto/elliptic: panic caused by oversized scalar  
2084085 - CVE-2022-29526 golang: syscall: faccessat checks wrong group  
2107342 - CVE-2022-30631 golang: compress/gzip: stack exhaustion in Reader.Read

5. JIRA issues fixed (https://issues.jboss.org/):

ROX-12799 - Release RHACS 3.72.0

6. References:

https://access.redhat.com/security/cve/CVE-2015-20107  
https://access.redhat.com/security/cve/CVE-2022-0391  
https://access.redhat.com/security/cve/CVE-2022-1292  
https://access.redhat.com/security/cve/CVE-2022-1586  
https://access.redhat.com/security/cve/CVE-2022-1785  
https://access.redhat.com/security/cve/CVE-2022-1897  
https://access.redhat.com/security/cve/CVE-2022-1927  
https://access.redhat.com/security/cve/CVE-2022-2068  
https://access.redhat.com/security/cve/CVE-2022-2097  
https://access.redhat.com/security/cve/CVE-2022-24675  
https://access.redhat.com/security/cve/CVE-2022-24921  
https://access.redhat.com/security/cve/CVE-2022-28327  
https://access.redhat.com/security/cve/CVE-2022-29154  
https://access.redhat.com/security/cve/CVE-2022-29526  
https://access.redhat.com/security/cve/CVE-2022-30631  
https://access.redhat.com/security/cve/CVE-2022-32206  
https://access.redhat.com/security/cve/CVE-2022-32208  
https://access.redhat.com/security/cve/CVE-2022-34903  
https://access.redhat.com/security/updates/classification/#moderate  
https://docs.openshift.com/acs/3.72/release_notes/372-release-notes.html

7. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYzH0ItzjgjWX9erEAQg2Yg//fDLYNktH9vd06FrD5L77TeiYnD/Zx+f5  
fk12roODKMOpcV6BmnOyPG0a6POCmhHn1Dn6bOT+7Awx0b9A9cXXDk6jytkpDhh7  
O0OxzWZVVvSzNe1TL3WN9vwZqSpAYON8euLBEb16E8pmEv7vXKll3wMQIlctp6Nr  
ey6DLL718z8ghXbtkkcGsBQqElM4jESvGm5xByMymfRFktvy9LSgTi+Zc7FY7gXL  
AHitJZiSm57D/pwUHvNltLLkxQfVAGuJXaTHYFyeIi6Z2pdDySYAXcr60mVd6eSh  
9/7qGwdsQARwmr174s0xMWRcns6UDvwIWifiXl6FUnTZFlia+lC3xIP1o2CXwoFP  
Fr7LpF0L9h5BapjSRv1w6qkkJIyJhw5v9VmZQoQ3joZqRQi0I6qLOcp92eik63pM  
i11ppoeDNwjpSST40Ema3j9PflzxXB7PKBUfKWwqNc2dnWDkiEhNaXOAZ7MqgdLo  
MB3enlKV4deeWOb5OA1Vlv/lAAJM0h5AOgTIBddYs3CDsyoK9fKm1UF/BEhcWMyr  
kV3AJ0/zzAK6ev4hQmP8Ug4SbdiHNdM3X1vgH54OVJ3Al3E1nAEyYmELNUITrvXV  
jJI5thbVwK78vOX9yWcmpZm879BnHnUPzGbS0lF5FVJOSZ8E7LvOE7lCM/dg094z  
0riGwT9O9Ys=  
=hArw  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-6714-01

mailcow is a mailserver suite. A vulnerability innversions prior to 2022-09 allows an attacker to craft a custom Swagger API template to spoof Authorize links. This could redirect a victim to an attacker controller place to steal Swagger authorization credentials or create a phishing page to steal other information. The issue has been fixed with the 2022-09 mailcow Mootember Update. As a workaround, one may delete the Swapper API Documentation from their e-mail server.


Receiving mails for wildcard alias addresses is really easy – but
sending mails from those any-aliases was not possible at all unless
every sender address was added as an explicit alias to the database.

By this change in the database query for allowed sender addresses, the
first finding \`not NULL\` (see \[\`SELECT COALESCE\`\](https://www.w3schools.com/sql/func\_sqlserver\_coalesce.asp) for how it works)
– either an exact alias \`mailbox@domain.tld\` or the wildcard alias \`@domain.tld\`
will be allowed to send mails as the given address ... without the need
of explicit definition within the database.

Update Version of Docker-Image according to \[related comment\](#4703 (comment))

 

\* build: harden integration\_tests.yml permissions

Signed-off-by: Alex <aleksandrosansan@gmail.com>

\* build: harden image\_builds.yml permissions

Signed-off-by: Alex <aleksandrosansan@gmail.com>

Signed-off-by: Alex <aleksandrosansan@gmail.com>
Co-authored-by: Niklas Meyer <62480600+DerLinkman@users.noreply.github.com>

 

Co-authored-by: Burak Buylu <burak@burtinet.com>
Co-authored-by: milkmaker <milkmaker@mailcow.de>

Co-authored-by: Burak Buylu <burak@burtinet.com>

\[API\] Update swagger version

Improve send-as behaviour

Tag

#docker