A prototype pollution vulnerability exists in the function copy in dom.js in the xmldom (published as @xmldom/xmldom) package before 0.8.3 for Node.js via the p variable.

CVE-2022-37616: xmldom/dom.js at bc36efddf9948aba15618f85dc1addfc2ac9d7b2 · xmldom/xmldom

An out of bounds write in hermes, while handling large arrays, prior to commit 06eaec767e376bfdb883d912cb15e987ddf2bda1 allows attackers to potentially execute arbitrary code via crafted JavaScript. Note that this is only exploitable if the application using Hermes permits evaluation of untrusted JavaScript. Hence, most React Native applications are not affected.

@@ -0,0 +1,51 @@ diff --git a/xplat/hermes/external/llvh/include/llvh/ADT/SmallVector.h b/xplat/hermes/external/llvh/include/llvh/ADT/SmallVector.h \--- a/xplat/hermes/external/llvh/include/llvh/ADT/SmallVector.h +++ b/xplat/hermes/external/llvh/include/llvh/ADT/SmallVector.h @@ -238,12 +238,16 @@ // Define this out-of-line to dissuade the C++ compiler from inlining it. template <typename T, bool isPodLike> void SmallVectorTemplateBase<T, isPodLike>::grow(size\_t MinSize) { \- if (MinSize > UINT32\_MAX) \- report\_bad\_alloc\_error("SmallVector capacity overflow during allocation"); \- // Always grow, even from zero. \- size\_t NewCapacity = size\_t(NextPowerOf2(this->capacity() + 2)); \- NewCapacity = std::min(std::max(NewCapacity, MinSize), size\_t(UINT32\_MAX)); + constexpr size\_t MinGrowth = 2; + size\_t NewCapacity = size\_t(NextPowerOf2(this->capacity() + MinGrowth)); + NewCapacity = static\_cast<unsigned>(std::max(NewCapacity, MinSize)); + // Ensure that NewCapacity did not overflow an unsigned int, + // and that the capacity in bytes will not overflow a size\_t. + if (NewCapacity <= this->capacity() || + NewCapacity < MinSize || + NewCapacity > size\_t(-1) / sizeof(T)) + report\_bad\_alloc\_error("SmallVector capacity overflow during allocation"); T \*NewElts = static\_cast<T\*>(llvh::safe\_malloc(NewCapacity\*sizeof(T)));  
// Move the elements over. diff --git a/xplat/hermes/external/llvh/lib/Support/SmallVector.cpp b/xplat/hermes/external/llvh/lib/Support/SmallVector.cpp \--- a/xplat/hermes/external/llvh/lib/Support/SmallVector.cpp +++ b/xplat/hermes/external/llvh/lib/Support/SmallVector.cpp @@ -42,13 +42,16 @@ /// on POD-like datatypes and is out of line to reduce code duplication. void SmallVectorBase::grow\_pod(void \*FirstEl, size\_t MinCapacity, size\_t TSize) { \- // Ensure we can fit the new capacity in 32 bits. \- if (MinCapacity > UINT32\_MAX) \- report\_bad\_alloc\_error("SmallVector capacity overflow during allocation"); + constexpr size\_t MinGrowth = 1; + size\_t NewCapacity = 2 \* capacity() + MinGrowth; // Always grow. + NewCapacity = static\_cast<unsigned>(std::max(NewCapacity, MinCapacity));  
\- size\_t NewCapacity = 2 \* capacity() + 1; // Always grow. \- NewCapacity = \- std::min(std::max(NewCapacity, MinCapacity), size\_t(UINT32\_MAX)); + // Ensure that NewCapacity did not overflow an unsigned int, + // and that the capacity in bytes will not overflow a size\_t. + if (NewCapacity <= this->capacity() || + NewCapacity < MinCapacity || + NewCapacity > size\_t(-1) / TSize) + report\_bad\_alloc\_error("SmallVector capacity overflow during allocation");  
void \*NewElts; if (BeginX == FirstEl) {

CVE-2022-32234: Re-sync with internal repository (#772) · facebook/hermes@06eaec7

The aeson library is not safe to use to consume untrusted JSON input. A remote user could abuse this flaw to produce a hash collision in the underlying unordered-containers library by sending specially crafted JSON data, resulting in a denial of service.

CVE-2022-3433: JSON Vulnerability in Haskell's Aeson library

A buffer underflow vulnerability exists in the way Hword of Hancom Office 2020 version 11.0.0.5357 parses XML-based office files. A specially-crafted malformed file can cause memory corruption by using memory before buffer start, which can lead to code execution. A victim would need to access a malicious file to trigger this vulnerability.

**SUMMARY**

A buffer underflow vulnerability exists in the way Hword of Hancom Office 2020 version 11.0.0.5357 parses XML-based office files. A specially-crafted malformed file can cause memory corruption by using memory before buffer start, which can lead to code execution. A victim would need to access a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Hancom Office 2020 Hancom Office 2020 11.0.0.5357

**PRODUCT URLS**

Hancom Office 2020 - https://office.hancom.com/

**CVSSv3 SCORE**

7.8 - CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-124 - Buffer Underwrite (‘Buffer Underflow’)

**DETAILS**

Hancom Office is considered one of the more popular Office suites used within South Korea.

After enabling PageHeap for the application and HwordApp.dll, attempting to open the malicious file results in the following exception in the debugger:

    (150c.1f44): Access violation - code c0000005 (first/second chance not available)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=131d1490 ebx=00ef9fa4 ecx=dcbaaaaa edx=00000001 esi=00ef9f64 edi=00ef9ea0
    eip=6a55d80c esp=00ef9dac ebp=00ef9de4 iopl=0         nv up ei pl zr na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200246
    HwordApp!SetInitFontCallbackFunc+0x4f619c:
    6a55d80c 8b01            mov     eax,dword ptr [ecx]  ds:002b:dcbaaaaa=????????
    

A few assembly instructions prior, we see the following code (we assume the HwordApp.dll is loaded at the base address of 0x6a010000):

    .text:6A55D803 loc_6A55D803:
    .text:6A55D803 mov     eax, [esi+0A30h]
    .text:6A55D809 mov     ecx, [eax-4]                                  (1)
    .text:6A55D80C mov     eax, [ecx]                                    (2)
    .text:6A55D80E call    dword ptr [eax+10h]                           (3)
    

The pointer is decremented by 4 at location (1) and is dereferenced at (2) where the code eventually crashes.

At location (1), eax holds the pointer to memory allocated in the heap. Since we have enabled PageHeap, we can see metadata related to this heap allocation, like allocation size, the stack trace of the allocating code, etc. In memory, these metadata reside just before the heap allocation returned to the application. We can examine the metadata with the following command:

    0:002> dt _DPH_BLOCK_INFORMATION eax-20
    ntdll!_DPH_BLOCK_INFORMATION
       +0x000 StartStamp       : 0xabcdaaaa
       +0x004 Heap             : 0x84801000 Void
       +0x008 RequestedSize    : 4
       +0x00c ActualSize       : 0x2c
       +0x010 FreeQueue        : _LIST_ENTRY [ 0x48010c0 - 0x12bd4230 ]
       +0x010 FreePushList     : _SINGLE_LIST_ENTRY
       +0x010 TraceIndex       : 0x10c0
       +0x018 StackTrace       : 0x050f2284 Void
       +0x01c EndStamp         : 0xdcbaaaaa
    

The code attempts to dereference a pointer with the erroneous value of 0xdcbaaaaa, which is the EndStamp magic value at the end of PageHeap metadata.

As evident in the RequestedSize field, the application requested an allocation of 4 bytes. However, the code effectively attempts to dereference a pointer that resides 4 bytes prior to that allocation.

After reversing the code, it was found that the application crashes in an attempt to parse XML data, specifically the </w:p> XML tag. The malicious file is in the .docx format, which is a .zip file containing various XML files. Unzipping the malicious file, we see the following in word/document.xml:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    ...
    <w:body></w:p></w:body>
    

The </w:p> XML tag denotes the end of a paragraph in the .docx format. Providing the open tag <w:p> before the end tag, the application does not crash. From our analysis, it was evident that the application keeps a vector-type data structure containing pointers of objects. When there is an open tag followed by a close tag, the vector holds two pointers with a total size of 8 bytes (2 pointers of 4 bytes each) and the code works correctly. When there is only the close tag, the code assumes there is another element in the vector, decrements the pointer to the vector by 4 and attempts to dereference and call the erroneous pointer.

At location (3) in the code listing above, we see this pointer being used as a target to an indirect call, in a typical behaviour to a virtual function table call in C++. As a result, the code will attempt to make a call to an erroneous pointer that resides in memory.

Using heap spraying techniques, an attacker could force the application to allocate memory that resides immediately before the buffer and make it contain arbitrary data. As a result, the attacker could be able to control the pointer that will eventually be used for the indirect call, resulting in arbitrary code execution.

**TIMELINE**

2022-07-14 - Vendor Disclosure  
2022-09-30 - Vendor Patch Release  
2022-10-04 - Public Release

CVE-2022-33896: TALOS-2022-1574 || Cisco Talos Intelligence Group

Categories: News
Tags: Microsoft SQL

Tags:  brute force

Tags:  Maggie

Tags:  Extended Stored Procedure

Researchers have found a backdoor that specifically targets Microsoft SQL servers. 



(Read more...)




The post Hundreds of Microsoft SQL servers found to be backdoored appeared first on Malwarebytes Labs.

Researchers at DCSO CyTec recently found a backdoor that specifically targets Microsoft SQL servers. The malware acts as an Extended Stored Procedure, which is a special type of extension used by Microsoft SQL servers.

After scanning approximately 600,000 servers worldwide, they found 285 servers infected with this backdoor, in 42 countries. The distribution shows a clear focus on the Asia-Pacific region.

**Extended Stored Procedure**

To understand how the malware works it is necessary to understand the role of an Extended Stored Procedure on a SQL server. Extended stored procedures are dynamic link library (DLL) files which are referenced by the SQL Server by having the extended stored procedure created, which then references functions or procedures within the DLL. The DLLs that are behind the extended stored procedures are typically created in a lower level language like C or C++.

Basically, the functions stored in the DLL can be triggered from the client application to Microsoft SQL Server and the extended stored procedure passes result sets and return parameters back to the server through the Extended Stored Procedure Application Programming Interface (API).

**Maggie**

Based on artifacts found in the malware, DCSO CyTec has dubbed this threat Maggie. According to its export directory, the file calls itself sqlmaggieAntiVirus_64.dll and only offers a single export called maggie.

Maggie uses the Extended Stored Procedure API to implement a fully functional backdoor controlled only using SQL queries. But to establish the connection an attacker has to drop the backdoor in a directory accessible by the Microsoft SQL server, and has to have valid credentials to load the Maggie Extended Stored Procedure into the server. Otherwise the server will never query the DLL for any functions. For now, it is unknown how the initial infection takes place. But there are some known vulnerabilities for Microsoft SQL server that may not have been patched by every organization.

**Capabilities**

Once installed, Maggie offers a variety of commands that allow the attacker to query for system information, interact with files and folders, execute programs, and to perform various network-related functions, including setting up port forwarding to make Maggie act as a bridge head into the server’s network environment.

Once enabled, Maggie separates the attacker's connections from the others, so legitimate users are able to use the server without any interference by Maggie. This reduces the chance of the users noticing something is wrong. The separation is done based on an IP mask that redirects any incoming connection to a set IP and port, if the source IP address matches the user-specified IP mask.

**Brute force**

Maggie’s command set also includes two commands that seem designed to allow it to brute force logins to other MSSQL servers. To start a brute force scan, the threat actor has to specify a target host, user and password list file previously uploaded to the infected server.

The backdoor logs successful logins and then checks whether they have administrator permissions. It is logical to assume that this is intended to increase the number of victims. What the underlying purpose of Maggie is, remains to be seen.

**Targets**

Since the backdoor depends on the setup of a Microsoft SQL server, the researchers conducted a scan on publicly reachable Microsoft SQL servers in order to determine how prevalent the identified backdoor is. The scan revealed 285 infected servers on a total of around 600,000 scanned servers.

The scan also showed that most of the infected servers were located in South Korea, India and Vietnam, followed by China and Taiwan in the fourth and fifth place. Infections in other countries appear to be incidental.

**Malwarebytes**

Malwarebytes users are protected from this threat, since our Artificial Intelligence module detected this backdoor as Malware.AI.4207982868 right off the bat.

Hundreds of Microsoft SQL servers found to be backdoored

Red Hat Security Advisory 2022-6813-01 - Red Hat Process Automation Manager is an open source business process management suite that combines process management and decision service management and enables business and IT users to create, manage, validate, and deploy process applications and decision services. This asynchronous security patch is an update to Red Hat Process Automation Manager 7. Issues addressed include XML injection, bypass, denial of service, and traversal vulnerabilities.

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

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

Synopsis:          Important: Red Hat Process Automation Manager 7.13.1 security update  
Advisory ID:       RHSA-2022:6813-01  
Product:           Red Hat Process Automation Manager  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:6813  
Issue date:        2022-10-05  
CVE Names:         CVE-2020-7746 CVE-2020-36518 CVE-2021-23436   
                   CVE-2021-44906 CVE-2022-0235 CVE-2022-0722   
                   CVE-2022-1365 CVE-2022-1650 CVE-2022-2458   
                   CVE-2022-21363 CVE-2022-21724 CVE-2022-23437   
                   CVE-2022-23913 CVE-2022-24771 CVE-2022-24772   
                   CVE-2022-24785 CVE-2022-26520 CVE-2022-31129   
=====================================================================

1. Summary:

An update is now available for Red Hat Process Automation Manager.

Red Hat Product Security has rated this update as having a security impact  
of Low. 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:

Red Hat Process Automation Manager is an open source business process  
management suite that combines process management and decision service  
management and enables business and IT users to create, manage, validate,  
and deploy process applications and decision services.

This asynchronous security patch is an update to Red Hat Process Automation  
Manager 7.

Security Fix(es):

* chart.js: prototype pollution (CVE-2020-7746)

* moment: inefficient parsing algorithm resulting in DoS (CVE-2022-31129)

* package immer before 9.0.6. A type confusion vulnerability can lead to a  
bypass of CVE-2020-28477 (CVE-2021-23436)

* artemis-commons: Apache ActiveMQ Artemis DoS (CVE-2022-23913)

* Business-central: Possible XML External Entity Injection attack  
(CVE-2022-2458)

* cross-fetch: Exposure of Private Personal Information to an Unauthorized  
Actor (CVE-2022-1365)

* jackson-databind: denial of service via a large depth of nested objects  
(CVE-2020-36518)

* jdbc-postgresql: postgresql-jdbc: Arbitrary File Write Vulnerability  
(CVE-2022-26520)

* jdbc-postgresql: Unchecked Class Instantiation when providing Plugin  
Classes (CVE-2022-21724)

* Moment.js: Path traversal  in moment.locale (CVE-2022-24785)

* org.drools-droolsjbpm-integration: minimist: prototype pollution  
(CVE-2021-44906)

* org.kie.workbench-kie-wb-common: minimist: prototype pollution  
(CVE-2021-44906)

* parse-url: Exposure of Sensitive Information to an Unauthorized Actor in  
GitHub repository ionicabizau/parse-url (CVE-2022-0722)

* xercesimpl: xerces-j2: infinite loop when handling specially crafted XML  
document payloads (CVE-2022-23437)

* eventsource: Exposure of Sensitive Information (CVE-2022-1650)

* mysql-connector-java: Difficult to exploit vulnerability allows a high  
privileged attacker with network access via multiple protocols to  
compromise MySQL Connectors (CVE-2022-21363)

* node-fetch: exposure of sensitive information to an unauthorized actor  
(CVE-2022-0235)

* node-forge: Signature verification failing to check tailing garbage bytes  
can lead to signature forgery (CVE-2022-24772)

* node-forge: Signature verification leniency in checking `digestAlgorithm`  
structure can lead to signature forgery (CVE-2022-24771)

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:

For on-premise installations, before applying the update, back up your  
existing installation, including all applications, configuration files,  
databases and database settings, and so on.

Red Hat recommends that you halt the server by stopping the JBoss  
Application Server process before installing this update. After installing  
the update, restart the server by starting the JBoss Application Server  
process.

The References section of this erratum contains a download link. You must  
log in to download the update.

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

2041833 - CVE-2021-23436 immer: type confusion vulnerability can lead to a bypass of CVE-2020-28477  
2044591 - CVE-2022-0235 node-fetch: exposure of sensitive information to an unauthorized actor  
2047200 - CVE-2022-23437 xerces-j2: infinite loop when handling specially crafted XML document payloads  
2047343 - CVE-2022-21363 mysql-connector-java: Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Connectors  
2050863 - CVE-2022-21724 jdbc-postgresql: Unchecked Class Instantiation when providing Plugin Classes  
2063601 - CVE-2022-23913 artemis-commons: Apache ActiveMQ Artemis DoS  
2064007 - CVE-2022-26520 postgresql-jdbc: Arbitrary File Write Vulnerability  
2064698 - CVE-2020-36518 jackson-databind: denial of service via a large depth of nested objects  
2066009 - CVE-2021-44906 minimist: prototype pollution  
2067387 - CVE-2022-24771 node-forge: Signature verification leniency in checking `digestAlgorithm` structure can lead to signature forgery  
2067458 - CVE-2022-24772 node-forge: Signature verification failing to check tailing garbage bytes can lead to signature forgery  
2072009 - CVE-2022-24785 Moment.js: Path traversal  in moment.locale  
2076133 - CVE-2022-1365 cross-fetch: Exposure of Private Personal Information to an Unauthorized Actor  
2085307 - CVE-2022-1650 eventsource: Exposure of Sensitive Information  
2096966 - CVE-2020-7746 chart.js: prototype pollution  
2103584 - CVE-2022-0722 parse-url: Exposure of Sensitive Information to an Unauthorized Actor in GitHub repository ionicabizau/parse-url  
2105075 - CVE-2022-31129 moment: inefficient parsing algorithm resulting in DoS  
2107994 - CVE-2022-2458 Business-central: Possible XML External Entity Injection attack

5. References:

https://access.redhat.com/security/cve/CVE-2020-7746  
https://access.redhat.com/security/cve/CVE-2020-36518  
https://access.redhat.com/security/cve/CVE-2021-23436  
https://access.redhat.com/security/cve/CVE-2021-44906  
https://access.redhat.com/security/cve/CVE-2022-0235  
https://access.redhat.com/security/cve/CVE-2022-0722  
https://access.redhat.com/security/cve/CVE-2022-1365  
https://access.redhat.com/security/cve/CVE-2022-1650  
https://access.redhat.com/security/cve/CVE-2022-2458  
https://access.redhat.com/security/cve/CVE-2022-21363  
https://access.redhat.com/security/cve/CVE-2022-21724  
https://access.redhat.com/security/cve/CVE-2022-23437  
https://access.redhat.com/security/cve/CVE-2022-23913  
https://access.redhat.com/security/cve/CVE-2022-24771  
https://access.redhat.com/security/cve/CVE-2022-24772  
https://access.redhat.com/security/cve/CVE-2022-24785  
https://access.redhat.com/security/cve/CVE-2022-26520  
https://access.redhat.com/security/cve/CVE-2022-31129  
https://access.redhat.com/security/updates/classification/#important

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

iQIVAwUBYz2bItzjgjWX9erEAQjghg/+IWxIByKM9Jd9SF+3RuzMy9vdHDNJnw64  
eJBHE2op5F2IXv8Iqq5zYyTtv8zk6kKzsGjH/fGy3Ha8/4zn1vCCzMImsYIts0qt  
WI6WR3p/4OM9P++HVqoNd9ZfvXEw4l7+noj+2hDfWqtmu0TGfIcmgHpNGnqqisix  
Lbaw7H+s6QruFiTF6cpols+zT/7PsbSoeK3RcBhgVwJHyYz4hqwFS6g0/jyaOYKp  
pEM0AMJF6TrFRNWs/KVSYKPWAkC7XYCGN47DG6ac7jCSyOWaJi50ANcSXL8ITEdS  
74PPhsicA/nhGjHf/QVBeqLiWPuBiPTaYBqkKP5YCduGLP+aJxXYeGCd9JOX1FZd  
KIk/B0XDHN4Pv4Puaim5x8WjZL4z6zSjnK60nXs2idbEmiBY+la6Dw1TYV2tA27G  
GWh+BaecKar1Crp8BTKuidFinDrN9FldfhRv7zS8gY8gLeTKyqaNFPdemzaGK7mD  
5pGUVxwuB8mqu4ZsrCdfekXyikQ6NAXp69S1NQMIkNY6NVlBcSElj9hu5G++T3LR  
a0fDTTeTVtLcW9m9JNpKlRwfUrc2r3/ODuQJk0pIPfw3DTscNllqnHPWTUnPH4Gq  
9CEEltjCrL/JLnpxHdYjxMWTB9XnnMi+yMziJnGRWA1v4NiYSPdjPkqZSsSBTFqC  
+TymeZzewhE=  
=Nji7  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-6813-01

Bento4 v1.6.0-639 was discovered to contain a heap overflow via the AP4_BitReader::ReadBit function in mp4mux.

**Summary**

Hello, I was testing my fuzzer and found three heap buffer overflow bugs in AP4\_Atom::TypeFromString(char const\*), AP4\_BitReader::ReadBit() and AP4\_BitReader::ReadBits(unsigned int). They come from mp4tag and mp4mux, respectively.

**Bug1**

Heap-buffer-overflow on address 0x602000000332 in mp4tag:

    root@728d9sls452:/fuzz-mp4tag/mp4tag# ./mp4tag --remove 1 ../out/crashes/mp4tag_poc_1 /dev/null
    =================================================================
    ==1647110==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000332 at pc 0x000000468f25 bp 0x7fff3510c600 sp 0x7fff3510c5f8
    READ of size 1 at 0x602000000332 thread T0
        #0 0x468f24 in AP4_Atom::TypeFromString(char const*) (/fuzz-mp4tag/mp4tag/mp4tag+0x468f24)
        #1 0x755566 in AP4_MetaData::Entry::FindInIlst(AP4_ContainerAtom*) const (/fuzz-mp4tag/mp4tag/mp4tag+0x755566)
        #2 0x75a3f2 in AP4_MetaData::Entry::RemoveFromFileIlst(AP4_File&, unsigned int) (/fuzz-mp4tag/mp4tag/mp4tag+0x75a3f2)
        #3 0x42fc2c in RemoveTag(AP4_File*, AP4_String&, bool) (/fuzz-mp4tag/mp4tag/mp4tag+0x42fc2c)
        #4 0x418531 in main (/fuzz-mp4tag/mp4tag/mp4tag+0x418531)
        #5 0x7fdb89b2ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #6 0x407f09 in _start (/fuzz-mp4tag/mp4tag/mp4tag+0x407f09)
    
    0x602000000332 is located 0 bytes to the right of 2-byte region [0x602000000330,0x602000000332)
    allocated by thread T0 here:
        #0 0x996920 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fdb8a1a9297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x418531 in main (/fuzz-mp4tag/mp4tag/mp4tag+0x418531)
        #3 0x7fdb89b2ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/fuzz-mp4tag/mp4tag/mp4tag+0x468f24) in AP4_Atom::TypeFromString(char const*)
    Shadow bytes around the buggy address:
      0x0c047fff8010: fa fa fd fd fa fa 04 fa fa fa fd fd fa fa 00 05
      0x0c047fff8020: fa fa 01 fa fa fa 01 fa fa fa fd fa fa fa 03 fa
      0x0c047fff8030: fa fa fd fa fa fa 06 fa fa fa 00 fa fa fa fd fa
      0x0c047fff8040: fa fa 04 fa fa fa fd fd fa fa fd fa fa fa 01 fa
      0x0c047fff8050: fa fa fd fa fa fa 00 00 fa fa 05 fa fa fa 00 00
    =>0x0c047fff8060: fa fa 02 fa fa fa[02]fa fa fa 05 fa fa fa fa fa
      0x0c047fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff80b0: 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
    ==1647110==ABORTING
    
    

**Bug2**

Heap-buffer-overflow on address 0x6020000000f8 in mp4mux (AP4\_BitReader::ReadBits):

    root@23iq42wasf35:/fuzz-mp4mux/mp4mux# \./mp4mux --track h264:../out/crashes/id\:000045\,sig\:06\,src\:000002\,op\:int32\,pos\:33\,val\:\+0\,470985 /dev/null
    =================================================================
    ==2473731==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000f8 at pc 0x000000649cb8 bp 0x7ffced185f90 sp 0x7ffced185f88
    READ of size 1 at 0x6020000000f8 thread T0
        #0 0x649cb7 in AP4_BitReader::ReadBits(unsigned int) (/fuzz-mp4mux/mp4mux/mp4mux+0x649cb7)
        #1 0x4d6040 in ReadGolomb(AP4_BitReader&) (/fuzz-mp4mux/mp4mux/mp4mux+0x4d6040)
        #2 0x4d6ef9 in AP4_AvcFrameParser::ParsePPS(unsigned char const*, unsigned int, AP4_AvcPictureParameterSet&) (/fuzz-mp4mux/mp4mux/mp4mux+0x4d6ef9)
        #3 0x4f01dd in AP4_AvcFrameParser::Feed(unsigned char const*, unsigned int, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/fuzz-mp4mux/mp4mux/mp4mux+0x4f01dd)
        #4 0x4ecbf1 in AP4_AvcFrameParser::Feed(void const*, unsigned int, unsigned int&, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/fuzz-mp4mux/mp4mux/mp4mux+0x4ecbf1)
        #5 0x4349a5 in main (/fuzz-mp4mux/mp4mux/mp4mux+0x4349a5)
        #6 0x7fb87db03c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #7 0x407df9 in _start (/fuzz-mp4mux/mp4mux/mp4mux+0x407df9)
    
    0x6020000000f8 is located 0 bytes to the right of 8-byte region [0x6020000000f0,0x6020000000f8)
    allocated by thread T0 here:
        #0 0xa84ba0 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fb87e17e297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x4f01dd in AP4_AvcFrameParser::Feed(unsigned char const*, unsigned int, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/fuzz-mp4mux/mp4mux/mp4mux+0x4f01dd)
        #3 0x4349a5 in main (/fuzz-mp4mux/mp4mux/mp4mux+0x4349a5)
        #4 0x7fb87db03c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/fuzz-mp4mux/mp4mux/mp4mux+0x649cb7) in AP4_BitReader::ReadBits(unsigned int)
    Shadow bytes around the buggy address:
      0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff8000: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fd
    =>0x0c047fff8010: fa fa 00 03 fa fa 06 fa fa fa 06 fa fa fa 00[fa]
      0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8060: 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
    ==2473731==ABORTING
    
    

**Bug3**

Heap-buffer-overflow on address 0x602000000158 in mp4mux (AP4\_BitReader::ReadBit):

    root@345sadsf12w332:/fuzz-mp4mux/mp4mux# ./mp4mux --track h264:../out/crashes/id\:000001\,sig\:06\,src\:000002\,op\:flip1\,pos\:8\,10085 /dev/null
    =================================================================
    ==1606856==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000158 at pc 0x00000064a882 bp 0x7ffd08428400 sp 0x7ffd084283f8
    READ of size 1 at 0x602000000158 thread T0
        #0 0x64a881 in AP4_BitReader::ReadBit() (/fuzz-mp4mux/mp4mux/mp4mux+0x64a881)
        #1 0x4d6456 in ReadGolomb(AP4_BitReader&) (/fuzz-mp4mux/mp4mux/mp4mux+0x4d6456)
        #2 0x4dcd9e in AP4_AvcFrameParser::ParseSliceHeader(unsigned char const*, unsigned int, unsigned int, unsigned int, AP4_AvcSliceHeader&) (/fuzz-mp4mux/mp4mux/mp4mux+0x4dcd9e)
        #3 0x4ed906 in AP4_AvcFrameParser::Feed(unsigned char const*, unsigned int, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/fuzz-mp4mux/mp4mux/mp4mux+0x4ed906)
        #4 0x4ecbf1 in AP4_AvcFrameParser::Feed(void const*, unsigned int, unsigned int&, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/fuzz-mp4mux/mp4mux/mp4mux+0x4ecbf1)
        #5 0x4349a5 in main (/fuzz-mp4mux/mp4mux/mp4mux+0x4349a5)
        #6 0x7fd9e3df9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
        #7 0x407df9 in _start (/fuzz-mp4mux/mp4mux/mp4mux+0x407df9)
    
    0x602000000158 is located 0 bytes to the right of 8-byte region [0x602000000150,0x602000000158)
    allocated by thread T0 here:
        #0 0xa84ba0 in malloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #1 0x7fd9e4474297 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x93297)
        #2 0x4ed906 in AP4_AvcFrameParser::Feed(unsigned char const*, unsigned int, AP4_AvcFrameParser::AccessUnitInfo&, bool) (/fuzz-mp4mux/mp4mux/mp4mux+0x4ed906)
        #3 0x4349a5 in main (/fuzz-mp4mux/mp4mux/mp4mux+0x4349a5)
        #4 0x7fd9e3df9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/fuzz-mp4mux/mp4mux/mp4mux+0x64a881) in AP4_BitReader::ReadBit()
    Shadow bytes around the buggy address:
      0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff8000: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fd
      0x0c047fff8010: fa fa 00 03 fa fa 06 fa fa fa fd fa fa fa fd fa
    =>0x0c047fff8020: fa fa 06 fa fa fa 07 fa fa fa 00[fa]fa fa fa fa
      0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8070: 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
    ==1606856==ABORTING
    

**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)  
Hao Zhang (NCNIPC of China)

Thank you for your time!

CVE-2022-41430: Some heap-buffer-overflow bugs in Bento4 · Issue #773 · axiomatic-systems/Bento4

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!

Tag

#c++