[FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Do not output duplicated frames on insufficient input

Michael Niedermayer michael at niedermayer.cc
Wed May 16 00:02:55 EEST 2018


On Mon, May 14, 2018 at 01:31:42AM +0200, Hendrik Leppkes wrote:
> On Mon, May 14, 2018 at 1:07 AM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > Fixes: Timeout
> > Fixes: 6383/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-6199846902956032
> >
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> >
> 
> This does not seem like an issue to fix, but a fundamental change in
> the behavior of the codec. It currently properly honors all frame
> types, including "empty" frames, which results in proper constant
> frame rate output.
> After the change, it just flat out ignores those and discards them
> without any further consideration.
> 
> Does not sound like a fuzzing or security related change to me, and
> possibly also quite the wrong thing to do.

having a small code that outputs empty frames is a denial of service
issue (which is a security issue). The attacker can with almost no bandwidth
requirement cause the decode side to spend almost arbitrary amounts of
CPU doing nothing usefull.

This problem is reduced when the copy case requires bandwidth proportional
to the resolution. As in a code per macroblock to skip it.
not one bit to make the player copy 1gb of data

said differently this increases the cost to an attacker per CPU cycle
she causes on the player.

In this particular case it also looks like that this is not
just a skip code but the decoder actually outputs empty frames on errors.

besides security its also more efficient not to send cloned frames
though the whole chain (which forces every component to do duplicated work
on each). And we avoid this in other decoders as well.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180515/948c032a/attachment.sig>


More information about the ffmpeg-devel mailing list