CVE-2022-43152 is a notable security vulnerability in tsMuxer (v2.6.16), a popular transport stream muxer often used in video editing and broadcasting workflows. At its core, this issue arises due to a heap overflow in the BitStreamWriter::flushBits() function found in /tsMuxer/bitStream.h. This post will break down the vulnerability, provide code examples, refer to original studies, and show how an attacker might take advantage of it—all in simple, beginner-friendly language.

What is tsMuxer?

tsMuxer is a free, open-source tool widely used for muxing (combining) various formats of audio and video streams into a single .ts or .m2ts file. The tool’s user base spans home enthusiasts to professional studios due to its simplicity and performance.

Official repo:  
tsMuxer on GitHub

Location in Code

The problem is inside the BitStreamWriter::flushBits() function, found in /tsMuxer/bitStream.h. In tsMuxer v2.6.16, the code does not properly check the size of write operations on the heap buffer, meaning that specially crafted input could cause the program to write past the ends of the allocated heap space.

Root Cause

It boils down to not verifying whether there’s enough memory to accommodate the flush operation. Usually, flush operations work by writing out all remaining bits in a buffer. If developers don’t make sure the underlying buffer is big enough, input data can spill past, corrupting data in memory.

Let's look at the relevant code (simplified for clarity)

void BitStreamWriter::flushBits()
{
    // Assume 'buffer' is a pointer to allocated heap memory
    // 'm_cache' contains data to flush, 'm_bitsLeft' indicates how many bits

    if (m_bitsLeft < 32)
    {
        *buffer++ = (uint8_t)(m_cache >> (24));
        // ... similar lines for other bytes ...
    }
}

The bug: There are no checks to ensure buffer has space for the bytes we are about to write! If the function writes more data than there’s space for, it will overwrite adjacent memory in the heap—a classic heap overflow.

Later versions (after v2.6.16) fix this by adding bounds checks before writing

if (remainingBufferSize >= N)
{
    // Safe to write N bytes
}
else
{
    // Error, do not write!
}


*See this commit for reference.*

Corrupt heap data (leading to weird bugs)

- Arbitrary code execution, if an attacker carefully crafts data to overwrite function pointers or control structures in the heap.

In the context of tsMuxer, if you feed it a malicious muxing file or stream, the program could be made to execute any code an attacker wants, potentially opening the door to deeper attacks.

Attack Scenario

1. Create Malicious Input File: An attacker prepares a video or stream file that purposely causes the buffer overflow during the flushBits() call.
2. Victim Runs tsMuxer: When processing this file, tsMuxer’s vulnerable function writes outside the bounds of the allocated buffer.
3. Trigger Code Execution or Crash: If the attacker crafted the file carefully, they could plant malicious payloads or just crash the program.

Proof-of-Concept Exploit

Here's a simple idea of what a proof-of-concept (PoC) could look like in C (details would depend on deeper analysis of tsMuxer's file format):

# dangerous_file.ts -- create a file that's malformed and causes flushBits() to overrun buffer
with open("exploit.ts", "wb") as f:
    f.write(b"A" * 4096)   # Write enough bytes to blow up the buffer during muxing
    # Append specifically-formatted muxer commands/data as needed

Then run

tsMuxer exploit.ts output.ts
# Should crash, or with a real exploit, could control instruction pointer

> Note: A real-world exploit would need careful study of the file format and memory layout. The above is for educational purposes only.

Official Advisory:

CVE-2022-43152 at NVD

GitHub Issue:

justdan96/tsMuxer#687
- Patch / Fix:  
 tsMuxer Commit Fixing Heap Overflow

Remediation

Upgrade to a fixed version!  
If you are using tsMuxer v2.6.16 or below, update immediately to the newest version.  
Get it here: tsMuxer Releases

Final Thoughts

Heap overflows are subtle but serious. Even trusted multimedia tools can have dangerous bugs, so always keep dependencies updated and be wary of processing untrusted content with any media software.

Timeline

Published on: 10/31/2022 19:15:00 UTC
Last modified on: 11/02/2022 00:20:00 UTC