mirror of
https://github.com/larksuite/cli.git
synced 2026-07-08 18:13:01 +08:00
e18ea9a2e8
The size==1 (64-bit "largesize") branch of all three MP4 box walkers (findMP4Box, readMp4DurationBytes, readMp4Duration) set boxEnd to the raw largesize instead of offset+largesize — even though the 32-bit branch right below correctly uses offset+size. Two consequences: - Correctness: for any MP4 that carries a 64-bit box size at a non-zero offset, the box walk is computed from the wrong end, so the moov/mvhd lookup is truncated and the media duration is silently lost. - Robustness/security (CWE-190): the unguarded uint64->int(64) conversion of a largesize with the high bit set yields a negative boxEnd. The in-memory walkers then assign it to offset and feed it back as a slice index (data[offset:]), panicking with "slice bounds out of range" and crashing the CLI on a crafted or corrupt MP4. This is reachable via URL-sourced IM media, whose bytes the caller does not control. Fix: compute boxEnd as offset+largesize (matching the 32-bit branch) and reject largesize values smaller than the 16-byte header or larger than the remaining input. Malformed media now honours the parsers' best-effort contract by returning 0/-1 instead of panicking, and the bounds guarantee the conversion can no longer overflow. Add regression tests covering both the overflow (must not panic) and a 64-bit box at a non-zero offset (must walk correctly).