r3n3r0/cve-2025-5915Proof-of-Concept-Exploit für einen Heap-Over-Read im libarchive RAR-v4-Filter (CVE-2025-5915) mit ASan-Reproduktion, Encoder und On-Device-Demonstration unter iOS 18.5.
Ein kontrollierter Heap-Over-Read / Memory-Disclosure im RAR-v4-Filterpfad von libarchive
(copy_from_lzss_window). Dieses Repository reproduziert das Problem Ende-zu-Ende: lokales ASan,
ein von Grund auf neu geschriebener RAR-v4-Encoder, der die Leak-Größe einstellt, und eine
On-Device-Demonstration unter iOS 18.5 mit der eigenen System-libarchive.2.dylib des iPhones.
parse_filter() liest eine Filter-blocklength (RAR-VM-Bytecode, bis zu 32 Bit)
und copy_from_lzss_window() führt ein memcpy über genau diese Byteanzahl aus dem LZSS-Fenster
aus, ohne zu prüfen, ob es in dictionary_size passt. Die Fenstergröße beträgt
rar_fls(unp_size) << 1 — der Angreifer kontrolliert beides. deklarieren →
32-Byte-Fenster, anfordern → ~240 KB benachbarter Heap werden in den
dekomprimierten Output gelesen.unp_size=16blocklength=0x3C000a612bf62 (libarchive 3.8.0) fügt if (blocklength > rar->dictionary_size) return 0;
hinzu (plus einen Wrap-around-Fix in copy_from_lzss_window).3.7.4 — die Versionszeichenkette unterscheidet sie nicht (siehe Write-up §7–8).Siehe das vollständige Write-up: writeup/cve-2025-5915.en.md
(Italienisch: writeup/cve-2025-5915.it.md).
Dieselbe ungeprüfte blocklength ist die Länge eines memcpy mit zwei Enden:
| Seite | fehlende Grenze | CVE | Fix |
|---|---|---|---|
| Quelle (LZSS-Fenster) | blocklength ≤ dictionary_size | CVE-2025-5915 (Lesen) | a612bf62, v3.8.0 |
Ziel (vm->memory, 0x40000) | blocklength ≤ VM_MEMORY_SIZE | CVE-2024-26256 (Schreiben) | b7b0c7c4, v3.7.5 |
Unter iOS 18.5 ist das Limit auf der Schreibseite (26256) bereits zurückportiert, die Schutzprüfung
auf der Leseseite (5915) jedoch nicht — unter iOS handelt es sich daher nur um ein Lesen
(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
Eigene erstellen: python3 poc/build_encoder.py out.rar <unp_size> <blocklength> [e8e9].
poc/RARLeak ist eine iOS-App, die einen Heap-Spray durchführt, die System-libarchive per
dlopen lädt, eine präparierte RAR-Datei einspeist und zählt, wie viel ihres eigenen Heaps im
Output zurückkommt. Legen Sie Ihr Signing-Team fest und bauen Sie:
cd poc/RARLeak && ./build.sh <device-udid> # set DEVELOPMENT_TEAM first (see build.sh)
Erwartet: Eine als 16 Byte deklarierte Datei ergibt ~196 KB Output, davon ~150 KB des platzierten
LK5915!!-Markers, der außerhalb der Grenzen gelesen wird. Das Ergebnis wird in Documents/ der
App geschrieben.
Apples libarchive.2.dylib (18.5 / 18.6) ist nicht enthalten (proprietär). Nur deren
SHA-1-Summen (analysis/SHA1SUMS.ios-dylibs) und die relevanten Disassembly-Auszüge. Eigene
Exemplare extrahieren Sie mit ipsw dyld extract <dyld_shared_cache> libarchive.2.dylib.
N-Day, behoben in libarchive 3.8.0 / iOS 18.6. Alles wurde auf der eigenen Hardware des Autors getestet. Bug gemeldet von JJLeo (libarchive Issue #2565), Forschung von Yifan Zhang (PLL, Peking University), Fix von Tobias Stoeckmann und Tim Kientzle. CVE-2024-26256-Fix von Tobias Stoeckmann. Nur für Forschungs- und Verteidigungszwecke.