[FFmpeg-devel] [PATCH] add av_shrink_packet

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Wed, Apr 08, 2009 at 10:55:27PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>>
>>> On Wed, Apr 08, 2009 at 10:49:55AM -0700, Baptiste Coudurier wrote:
>>>> On 4/8/2009 2:29 AM, Reimar D?ffinger wrote:
>>>>> On Tue, Apr 07, 2009 at 06:02:39PM -0700, Baptiste Coudurier wrote:
>>>>>> On 4/7/2009 5:49 PM, Michael Niedermayer wrote:
>>>>>>> and decoders have to deal with nonsense input anyway, throwing such
>>>>>>> away at demuxer level doesnt feel correct to me
>>>>>> Well, I tend to agree but this is only good if someone actually fixes
>>>>>> crashes in decoder...
>>>>> [...]
>>>>>>> maybe we could set some flag in AVPacket to indicate that a packet is
>>>>>>> possibly damaged, iam not sure if this would be of any use, but a user
>>>>>>> application could at least drop such packets if its author thinks its
>>>>>>> better though i dont really think it is ...
>>>>>> Well when you know that decoder is not error proof regarding partial
>>>>>> packets, it certainly is IMHO.
>>>>> IMO that is not a valid argument, because such a decoder is a major
>>>>> security issue and needs to be fixed ASAP.
>>>> It is a perfectly valid argument.
>>>>
>>>> You just cannot predict bugs and considering complexity of some codecs
>>>> you may just don't exactly know if there are bugs in the code, you don't
>>>> know about weird cases.
>>>>
>>>> It would be _safer_ in any case to discard these packets.
>>> I can't follow that reasoning, removing any chance that the bugs are
>>> triggered for "normal" files while it is still trivial to craft
>>> files that trigger them IMO does not even qualify as "security by
>>> obscurity".
>> I'd rather have a frame skipped than a crash for a slightly damaged
>> file, even if it's possible to craft a file that crashes the decoder.
> 
> iam sure we all agree but what i and i belive reimar too is afraid is
> that this hides serious seurity bugs, i mean
> 
> A we drop damaged frames (incomplete or even xiph crc style checks)
> -> this means that a buggy decoder wont crash
> -> we wont be aware of the problem
>
> B we dont drop damaged frames
> -> this means that a buggy decoder will crash
> -> user will eventually submit a bugreports
> -> some user or we might eventually fix it

Yes ! Let's open all firewalls because anyway we should fix all the
applications and/or users.

Hopefully the real world is more reasonable.

Btw, it might be more exact to remove "we" considering roundup status.

> if the bug is exploitable B is alot better than A
> 
> also seveal of our decoders support advanced error concealment and can
> do alot better than just droping a frame

Like H.264 decoder ? ;)

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org