CVE-2025-5915 — libarchive RAR v4 ヒープ過剰読み取り（iOS 18.5 実機での実証付き）

libarchive の RAR v4 フィルタ経路（copy_from_lzss_window）における、攻撃者が制御可能な ヒープ過剰読み取り / メモリ情報漏えい です。このリポジトリは、これをエンドツーエンドで再現します。すなわち、ローカルの ASan、漏えいサイズを調整できる自作の RAR v4 エンコーダ、そして iPhone 自身のシステム libarchive.2.dylib を使用した iOS 18.5 での 実機 デモです。

• 脆弱性: parse_filter() はフィルタの blocklength（RAR-VM バイトコード、最大 32 ビット）を読み取り、copy_from_lzss_window() は、そのバイト数が dictionary_size に収まるかをチェックせずに、LZSS ウィンドウから memcpy で読み出します。ウィンドウサイズは rar_fls(unp_size) << 1 です。攻撃者は両方（unp_size と blocklength）を制御できます。unp_size=16 と宣言すると 32 バイトのウィンドウになり、blocklength=0x3C000 を指定すると、隣接するヒープの約 240 KB が展開出力に読み出されます。
• 修正: コミット a612bf62（libarchive 3.8.0）で、if (blocklength > rar->dictionary_size) return 0; が追加されました（copy_from_lzss_window のラップアラウンド修正も含む）。
• iOS: 18.5（22F76）は libarchive 3.7.4 を搭載しており脆弱です。18.6（22G86）はバックポート済みです。どちらも 3.7.4 と報告するため、バージョン文字列では区別できません（writeup §7–8 参照）。

完全な技術記事はこちら: writeup/cve-2025-5915.en.md（イタリア語版: writeup/cve-2025-5915.it.md）。

1 つの memcpy、2 つの CVE

チェックされない同じ blocklength が、2 つの端点を持つ 1 つの memcpy の長さになっています:

iOS 18.5 では、書き込み側の上限（26256）はすでにバックポートされていますが、読み取り側のガード（5915）はバックポートされていません。そのため、iOS ではこれは 読み取りのみ になります（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)

再現手順（ローカル、macOS/Linux）

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

自分で作成する場合: python3 poc/build_encoder.py out.rar <unp_size> <blocklength> [e8e9]。

再現手順（実機、iOS ≤ 18.5）

poc/RARLeak は、ヒープをスプレーし、システムの libarchive を dlopen し、細工した RAR を読み込ませて、出力に自分のヒープがどれだけ返ってくるかを数える iOS アプリです。署名チームを設定してビルドします:

cd poc/RARLeak && ./build.sh <device-udid>        # set DEVELOPMENT_TEAM first (see build.sh)

期待される結果: 16 バイトと宣言されたファイルから約 196 KB の出力が得られ、そのうち約 150 KB は、仕込まれた LK5915!! マーカーが範囲外読み取りされたものです。結果はアプリの Documents/ に書き込まれます。

iOS バイナリに関する注意

Apple の libarchive.2.dylib（18.5 / 18.6）は、プロプライエタリのため 含まれていません。含まれているのは、その SHA-1（analysis/SHA1SUMS.ios-dylibs）と関連する逆アセンブリの抜粋のみです。自分で抽出するには ipsw dyld extract <dyld_shared_cache> libarchive.2.dylib を実行してください。

クレジットと倫理

N-day の脆弱性で、libarchive 3.8.0 / iOS 18.6 で修正済みです。すべて著者自身のハードウェアでテストされています。バグ報告は JJLeo（libarchive issue #2565）、調査は Yifan Zhang（北京大学 PLL）、修正は Tobias Stoeckmann と Tim Kientzle によるものです。CVE-2024-26256 の修正は Tobias Stoeckmann によるものです。研究および防御目的でのみ使用してください。