[
https://issues.apache.org/jira/browse/TIKA-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096462#comment-18096462
]
ASF GitHub Bot commented on TIKA-4777:
--------------------------------------
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.
```
> Extract QuickTime timed metadata (mebx) tracks
> ----------------------------------------------
>
> Key: TIKA-4777
> URL: https://issues.apache.org/jira/browse/TIKA-4777
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> Apple Live Photo videos mark the moment the paired still image was
> captured in a timed metadata track: the sample description declares the
> format 'mebx' with a keys structure containing
> com.apple.quicktime.still-image-time. The item value itself is always -1;
> the actual time is the presentation time of that sample, derived from the
> track's sample tables.
> Everything needed lives in the moov box, no mdat access is required:
> - mdhd: track timescale
> - stsd: detect the mebx sample entry and its still-image-time key
> - stts and elst: an empty edit shifts the single one-tick sample to the
> still moment
> Example from a real Live Photo video (iPhone 15 Pro, iOS 18.5): the
> still-image-time track has timescale 600, an edit list with an empty edit
> of 740 units followed by the sample, giving a still time of 1.2333 s.
> Neither the current MP4 handler (which reads the static keys/ilst
> metadata, TIKA-2861) nor the underlying metadata-extractor exposes timed
> metadata tracks; ExifTool only surfaces the constant -1 marker value.
> Note that the Apple maker note tag 0x0017 in the paired image
> (historically documented as "LivePhotoVideoIndex") does not encode a
> usable time on current iOS versions, so the video track is the only
> reliable source for this timestamp.
> Proposal: extend TikaMp4BoxHandler to accept the relevant trak child
> boxes, correlate mdhd/stsd/stts/elst per track, and emit the still time
> as metadata (e.g. com.apple.quicktime.still-image-time, in
> microseconds).
> Related: TIKA-2861 (QuickTime item-list metadata), TIKA-4776 (image-side
> Apple maker note, LONG8), TIKA-852.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
