[FFmpeg-devel] [PATCH] add av_shrink_packet

[Baptiste Coudurier]

Baptiste Coudurier wrote:
> 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.

Well, I was clearly extrapolating too much on this one. What I said was
exaggerated.

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

Please disregard this sentence, it was deliberately offensive and rude.
I'm sorry.

>> 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 ? ;)

Well, IIRC H.264 decoder doesn't have concealment yet, right ? Sorry if
I was wrong.

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