[FFmpeg-trac] #9738(ffplay:closed): Malicious webm video
FFmpeg
trac at avcodec.org
Wed Sep 21 20:03:06 EEST 2022
#9738: Malicious webm video
----------------------------------+-----------------------------------
Reporter: c0re100 | Owner: (none)
Type: defect | Status: closed
Priority: critical | Component: ffplay
Version: 4.4.1 | Resolution: invalid
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
----------------------------------+-----------------------------------
Comment (by Athari):
Replying to [comment:2 Michael Niedermayer]:
> as mkver said.
> If i word it differently,
> A valid file can require arbitrary amounts of memory. -max_pixels allows
to limit resolution based memory consumption
How is a 512x512 video correct if it has 15000x15000 data inside it with
apparently no way for user to tell it apart? (Even relatively low level
tools like MKVToolNix Info Tool don't show this.)
This video leads to app crashes due to lack of any sanity checks. It's no
different to ZIP bombs, XML entity bombs, JSON depth bombs etc. These are
often dealt with in libraries using various sanity/safety checks enabled
by default, even though the files are technically valid.
I think restricting max pixels to width x height x 4 (?) would work in
almost all cases, and it's people who do want to accept these weirdly
constructed files should be expected to use an option like
"unresctricted_max_pixels".
This file leads to crashes due to OOM errors. This can cause OS to crash.
This can be abused in denial-of-service attacks. It's impractical to
report this issue to thousands of applications and services and expect
every developer to implement sanity checks manually. Something needs to be
done by default.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9738#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list