r3n3r0/cve-2025-5915Exploit de prova de conceito para um over-read de heap no filtro RAR v4 do libarchive (CVE-2025-5915), com reprodução por ASan, encoder e demonstração em dispositivo iOS 18.5.
Um heap over-read / vazamento de memória controlado no caminho de filtro RAR v4 do libarchive (copy_from_lzss_window). Este repositório reproduz o problema de ponta a ponta: ASan local, um encoder RAR v4 escrito do zero que ajusta o tamanho do vazamento e uma demonstração no dispositivo em iOS 18.5 usando a libarchive.2.dylib do próprio sistema do telefone.
parse_filter() lê um blocklength de filtro (bytecode RAR-VM, até 32 bits) e copy_from_lzss_window() faz memcpy dessa quantidade de bytes para fora da janela LZSS sem verificar se cabe em dictionary_size. O tamanho da janela é rar_fls(unp_size) << 1 — o atacante controla ambos. Declare → janela de 32 bytes, peça → leia ~240 KB do heap adjacente para a saída descomprimida.unp_size=16blocklength=0x3C000a612bf62 (libarchive 3.8.0) adiciona if (blocklength > rar->dictionary_size) return 0; (além de uma correção de wrap-around em copy_from_lzss_window).3.7.4 — a string de versão não os distingue (ver artigo §7–8).Veja o artigo completo: writeup/cve-2025-5915.en.md (italiano: writeup/cve-2025-5915.it.md).
O mesmo blocklength sem verificação é o comprimento de um memcpy com duas extremidades:
| lado | limite ausente | CVE | correção |
|---|---|---|---|
| origem (janela LZSS) | blocklength ≤ dictionary_size | CVE-2025-5915 (leitura) | a612bf62, v3.8.0 |
destino (vm->memory, 0x40000) | blocklength ≤ VM_MEMORY_SIZE | CVE-2024-26256 (escrita) | b7b0c7c4, v3.7.5 |
No iOS 18.5, o limite do lado de escrita (26256) já foi incorporado via backport, mas a proteção do lado de leitura (5915) não — portanto, no iOS isto é apenas leitura (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
Crie o seu próprio: python3 poc/build_encoder.py out.rar <unp_size> <blocklength> [e8e9].
poc/RARLeak é um app iOS que inunda seu heap, faz dlopen da libarchive do sistema, alimenta um RAR criado sob medida e conta quanto do próprio heap retorna na saída. Defina sua equipe de assinatura e compile:
cd poc/RARLeak && ./build.sh <device-udid> # set DEVELOPMENT_TEAM first (see build.sh)
Esperado: um arquivo declarado com 16 bytes produz ~196 KB de saída, dos quais ~150 KB são o marcador LK5915!! plantado, lido fora dos limites. O resultado é gravado em Documents/ do app.
A libarchive.2.dylib da Apple (18.5 / 18.6) não está incluída (proprietária). Apenas os SHA-1 delas (analysis/SHA1SUMS.ios-dylibs) e os trechos de desmontagem relevantes estão. Extraia a sua com ipsw dyld extract <dyld_shared_cache> libarchive.2.dylib.
N-day, corrigido no libarchive 3.8.0 / iOS 18.6. Tudo foi testado no hardware do próprio autor. Bug relatado por JJLeo (issue #2565 do libarchive), pesquisa por Yifan Zhang (PLL, Universidade de Pequim), correção por Tobias Stoeckmann e Tim Kientzle. Correção da CVE-2024-26256 por Tobias Stoeckmann. Apenas para uso em pesquisa e defesa.