r3n3r0/cve-2025-5915Proof-of-concept exploit for a heap over-read in libarchive RAR v4 filter (CVE-2025-5915) with ASan reproduction, encoder, and on-device iOS 18.5 demonstration.
A controlled heap over-read / memory-disclosure in libarchive's RAR v4 filter path
(copy_from_lzss_window). This repo reproduces it end to end: local ASan, a from-scratch
RAR v4 encoder that dials the leak size, and an on-device demonstration on iOS 18.5
using the phone's own system libarchive.2.dylib.
parse_filter() reads a filter blocklength (RAR-VM bytecode, up to 32 bits)
and copy_from_lzss_window() memcpys that many bytes out of the LZSS window without
checking it fits dictionary_size. Window size is rar_fls(unp_size) << 1 — attacker
controls both. Declare unp_size=16 → 32-byte window, ask blocklength=0x3C000 → read
~240 KB of adjacent heap into the decompressed output.a612bf62 (libarchive 3.8.0) adds if (blocklength > rar->dictionary_size) return 0;
(plus a wrap-around fix in copy_from_lzss_window).3.7.4 — the version string doesn't distinguish them (see writeup §7–8).See the full write-up: writeup/cve-2025-5915.en.md
(Italian: writeup/cve-2025-5915.it.md).
The same unchecked blocklength is the length of one memcpy with two ends:
| side | missing bound | CVE | fix |
|---|---|---|---|
| source (LZSS window) | blocklength ≤ dictionary_size | CVE-2025-5915 (read) | a612bf62, v3.8.0 |
dest (vm->memory, 0x40000) | blocklength ≤ VM_MEMORY_SIZE | CVE-2024-26256 (write) | b7b0c7c4, v3.7.5 |
On iOS 18.5 the write-side cap (26256) is already backported but the read-side guard (5915)
is not — so on iOS this is a read only (analysis/two_cve_unification.md).
writeup/ full technical article (EN + IT)
poc/
build_bigleak.py shrink unp_size in a real archive + repair header CRC-16
build_encoder.py from-scratch RAR v4 encoder; dials blocklength (leak size)
plant.c macOS realloc interpose to plant a secret after the window
*.rar proof-of-concept archives (see poc/README.md)
RARLeak/ on-device iOS harness (Xcode project)
analysis/ ASan logs, iOS patch-diff (disassembly), notes, isolated guard patch
device-proof/ output of the on-device run (iPhone, iOS 18.5)
git clone https://github.com/libarchive/libarchive && cd libarchive && git checkout v3.7.4
CC=clang CFLAGS="-fsanitize=address -g -O1" LDFLAGS="-fsanitize=address" \
cmake -B build-asan -DENABLE_TEST=OFF . && cmake --build build-asan --target bsdtar
ASAN_OPTIONS=detect_leaks=0 build-asan/bin/bsdtar -xOf poc/enc_0x40000.rar >/dev/null
# -> AddressSanitizer: heap-buffer-overflow READ of size 262112
Craft your own: python3 poc/build_encoder.py out.rar <unp_size> <blocklength> [e8e9].
poc/RARLeak is an iOS app that sprays its heap, dlopens the system libarchive, feeds a
crafted RAR, and counts how much of its own heap comes back in the output. Set your signing
team and build:
cd poc/RARLeak && ./build.sh <device-udid> # set DEVELOPMENT_TEAM first (see build.sh)
Expected: a 16-byte-declared file yields ~196 KB of output, ~150 KB of it the planted
LK5915!! marker read out of bounds. Result is written to the app's Documents/.
Apple's libarchive.2.dylib (18.5 / 18.6) is not included (proprietary). Only their
SHA-1s (analysis/SHA1SUMS.ios-dylibs) and the relevant disassembly excerpts are. Extract
your own with ipsw dyld extract <dyld_shared_cache> libarchive.2.dylib.
N-day, fixed in libarchive 3.8.0 / iOS 18.6. Everything was tested on the author's own hardware. Bug reported by JJLeo (libarchive issue #2565), research by Yifan Zhang (PLL, Peking University), fix by Tobias Stoeckmann and Tim Kientzle. CVE-2024-26256 fix by Tobias Stoeckmann. For research and defensive use only.