[FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Do not output duplicated frames on insufficient input
h.leppkes at gmail.com
Wed May 16 01:29:16 EEST 2018
On Tue, May 15, 2018 at 11:02 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> 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.
It makes no real difference if its less efficient or whatever - if a
codec specification asks for this behavior, then our decoders should
act accordingly. Generating vfr decoder output from a cfr input stream
is not in any way a good idea.
More information about the ffmpeg-devel