7-Zip is one of the most popular free and open-source file archivers used worldwide for compressing and decompressing files in various formats. However, like any complex software, 7-Zip can have vulnerabilities that criminals may exploit.

In this long read, we’ll break down CVE-2023-40481—a serious security flaw in 7-Zip’s handling of SquashFS files (the .sqfs format). This vulnerability may allow remote attackers to execute code on a victim’s computer simply by tricking them into opening a malicious file or visiting a booby-trapped website.

We’ll cover the root cause, walk through the vulnerability with a simplified code example, and discuss exploitation. You’ll also find key references if you want to go deeper into the technical details.

What is CVE-2023-40481?

CVE-2023-40481 (also known as ZDI-CAN-18589) is an out-of-bounds write vulnerability in 7-Zip’s parsing of SquashFS files. This vulnerability was responsibly disclosed via the Zero Day Initiative.

Impact: Remote Code Execution (RCE)

- User Interaction: Required (user must open a malicious .sqfs file or visit a malicious webpage)
- CVE Details: NIST CVE-2023-40481
- ZDI Advisory: ZDI-23-1503

A Simple Explanation

When 7-Zip parses a SquashFS file, it reads metadata and file contents into memory buffers. The vulnerable code *does not properly check* that the data from the file fits within the buffer. If an attacker crafts a malformed SquashFS file with oversized data, 7-Zip may write that data past the end of the buffer—corrupting memory.

Let’s look at a simplified version of the vulnerable routine in C++-like pseudocode

void parseSquashFSHeader(const uint8_t* data, size_t len) {
    uint8_t buffer[64];
    // ... some code ...
    size_t header_length = extractHeaderLength(data); // attacker controlled
    // Vulnerable code: no bounds check for 'header_length'
    memcpy(buffer, data, header_length); // Can overwrite buffer
    // ... further processing ...
}

If header_length is larger than 64, memcpy will write past the buffer, potentially overwriting other memory. An attacker can control both the content (data) and the size (header_length).

The issue: 7-Zip doesn't properly verify that header_length fits in buffer.

Exploit Scenario: Remote Code Execution

A crafted SquashFS file, when opened in 7-Zip, can hijack the program’s execution flow, ultimately running attacker-supplied code.

The attacker creates a malicious .sqfs file with a specially crafted header.

2. The attacker emails this file to the victim or hosts it on a website, persuading the victim to open it.

The attacker’s payload (e.g., shellcode) is executed within the context of 7-Zip.

No privilege escalation occurs by default, but if the user has high privileges, so does the payload.

Proof-of-Concept (PoC) Snippet

Here’s a hypothetical PoC (don’t run this on a production system!) showing how you might trigger an OOB write in a vulnerable parsing routine:

with open("exploit.sqfs", "wb") as f:
    f.write(b"SQSH")                               # Magic bytes for SquashFS
    f.write(b"\xFF" * 256)                         # Overlong "header" to trigger overflow
    # (In reality, you’d need to follow the SquashFS file structure)

Opening exploit.sqfs in an unpatched 7-Zip could crash the program or, if the payload is correct, execute attacker code.

Mitigation and Recommendations

Vulnerable Versions: Look for your version’s status here.

Patch Status: Check 7-Zip’s official site for the latest fixed releases.

References and Further Reading

- ✉️ Zero Day Initiative ZDI-23-1503
- 🐞 NIST’s CVE-2023-40481 Detail Page
- 📦 7-Zip Official Download
- 🧑‍💻 SquashFS Format Documentation

Conclusion

CVE-2023-40481 shows that even trusted, widely-used utilities like 7-Zip can harbor dangerous flaws. Out-of-bounds write bugs like this are a top target for attackers because they can turn simple file parsing into remote code execution.

Action Step: Update your 7-Zip today, don’t open suspicious files, and stay on top of security news!

Have questions or want a demo PoC? Let us know in the comments. Stay safe!

Timeline

Published on: 05/03/2024 03:15:21 UTC
Last modified on: 06/05/2024 20:02:31 UTC