Opened 2 years ago

Closed 2 years ago

Last modified 20 months ago

#9738 closed defect (invalid)

Malicious webm video

Reported by: c0re100 Owned by:
Priority: critical Component: ffmpeg
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: When using ffplay to play that webm file, ffplay will consuming 4-6GB RAM.

How to reproduce:

  1. ffplay sticker.webm
  2. Check your task manager
  3. ffplay RAM usage is growing up/down as unexpected
ffmpeg -version
ffmpeg version 4.4.1-essentials_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 11.2.0 (Rev1, Built by MSYS2 project)

Attachments (1)

sticker.webm (244.0 KB ) - added by c0re100 2 years ago.

Download all attachments as: .zip

Change History (5)

by c0re100, 2 years ago

Attachment: sticker.webm added

comment:1 by mkver, 2 years ago

This file contains parts with dimensions 512x512 and parts with dimensions 15000x15000. The latter of course leads to big allocations, in particular with a frame-threaded codec like VP9. There exists an option to mitigate such issues: max_pixels. It is not really possible to "fix" this as these files can't really be distinguished from malicious files.

comment:2 by Michael Niedermayer, 2 years ago

Resolution: invalid
Status: newclosed

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

in reply to:  2 comment:3 by Athari, 20 months ago

Replying to 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.

comment:4 by Carl Eugen Hoyos, 20 months ago

Component: ffplayffmpeg
Version: 4.4.1git-master

There is also -max_alloc

Note: See TracTickets for help on using tickets.