[FFmpeg-devel] [PATCH] add av_shrink_packet

Måns Rullgård mans
Wed Apr 8 23:55:27 CEST 2009


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.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list