GHSA-g77h-45rf-hcx4 ExifReader HEIC/AVIF ISO-BMFF parser throws uncaught RangeError on truncated boxes
SummaryExifReader 4.40.0 can throw an uncaught `RangeError: Offset is outside the bounds of the DataView` while parsing crafted HEIC/AVIF files. The file only needs a valid leading `ftyp` box with a HEIC/AVIF major brand followed by a malformed ISO-BMFF box, such as an empty 8-byte `free` box or a truncated extended-size box.This is reachable through the public `ExifReader.load()` API for in-memory buffers and through the async file/URL loaders when an application parses attacker-supplied images. In applications that do not wrap every parse in a defensive try/catch, a single uploaded or fetched image can abort the request/worker and cause a denial of service.Credit requested: Yaohui Wang.Affected version testednpm package: `exifreader`Version: `4.40.0`Repository commit tested: `8cb0261a26b7d986955fe0a6780f076dcb7902e7`Root causeThe ISO-BMFF parser assumes that every top-level box with at least an 8-byte header also has enough bytes for the fields required by its parsed form. In `src/image-header-iso-bmff.js`:`findMetaBox()` calls `parseBox(dataView, offset)` while only checking that `offset + 8 <= dataView.byteLength`.`parseBox()` calls `getBoxLength()` and then unconditionally reads fields such as the full-box version byte for `meta`/`iloc`/`iinf`/`idat` boxes.`getBoxLength()` handles `boxLength === 1` by calling `hasEmptyHighBits(dataView, offset)`, which reads `dataView.getUint32(offset + 8)` without first checking that the 64-bit extended size field is present.As a result, syntactically small or truncated boxes after a valid HEIC/AVIF `ftyp` box escape the format-detection catch blocks and throw from the main parsing path.ReproductionRun this from the repository root against the committed `dist/exif-reader.js` bundle:Observed output on Node v23.11.0 with ExifReader 4.40.0:A second variant triggers the extended-size path:That throws from `hasEmptyHighBits()` / `getBoxLength()` because the extended-size high/low fields are not present.Expected behaviorMalformed/truncated metadata boxes should be handled like other malformed metadata in the project: return only the successfully parsed file type/metadata, return no app markers, or throw a controlled project-specific error. A safe JavaScript bounds error should not escape from the parser for an attacker-controlled image container.Security impactThis is a denial-of-service issue for services that parse user-provided HEIC/AVIF files with ExifReader. A minimal attacker-controlled image buffer can cause an unhandled exception in the parser and abort the surrounding request/worker if the embedding application does not catch every parse error.Suggested severity: Medium. Suggested CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L`.Suggested fixAdd explicit bounds checks before every `DataView` read in the ISO-BMFF box parser, especially:before reading the 64-bit extended size fields in `getBoxLength()`;before reading the full-box version byte in `parseBox()`;before descending into `parseSubBoxes()` when a declared box length exceeds available bytes;ensure `findMetaBox()` breaks on boxes whose declared length is invalid or not fully present.A regression test should cover `ftyp/heic` and `ftyp/avif` followed by an 8-byte empty `free`/unknown box and by a truncated extended-size box.
CVSS v3.1 score: 5.3