tballison commented on PR #2936:
URL: https://github.com/apache/tika/pull/2936#issuecomment-4980578460
From my agent:
```
One real finding (DoS/robustness):
TikaMp4MetaHandler.processSampleDescription does getBytes((int) entrySize - 8)
where entrySize is a uint32 only guarded by < 16. A crafted mebx stsd with
entrySize = 0xFFFFFFFF gives (int)-1
- 8 = -9; getBytes's bounds check passes for a negative count and hits new
byte[-9] → NegativeArraySizeException,
which escapes both Mp4Reader's catch (IOException) and MP4Parser's catch
(RuntimeSAXException), out of parse().
Reproduced by patching the one-track fixture's entry size: threw
java.lang.NegativeArraySizeException: -9
(pristine control parses clean). New to this PR (stock
Mp4MetaHandler.processSampleDescription is empty).
One-line fix:
if (entrySize < 16 || entrySize - 8 > reader.available()) { return; }
No other DoS/OOM/loop concerns: all loops are bounded or strictly advance
(every pos += size has a size < 8 →
break guard); getBytes bounds-checks before allocating so oversized
positive counts throw EOF without allocating;
payloads are bounded by Mp4Reader's box-size limits; keyNames growth is
bounded.
Minor (non-blocking):
- The trak-container emptyEditDuration reset is correct but not actually
exercised — every meta track after track
1 has a foreign key or >1 sample, so a leaked value never reaches an emit.
A real regression test needs a
single-sample still-image-time track with no leading empty edit placed
after a delayed track, asserting 0.
- hdlr branch keys on handler_type == 'meta'; a (non-real-world)
moov-level meta/hdlr with type 'meta' would
bypass keys/ilst. Latent only.
- set vs add on STILL_IMAGE_TIME: fine now that it's one scalar
(last-writer-wins), just noting.
- ~4 consecutive blank lines after processEditList.
quicktime:still-image-time shape is right: internalReal is required for
set(Property, long) and serializes to
exactly "1233333"/"0"; movie-timescale divisor is the correct unit for
elst segment_duration per ISO 14496-12.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
