[FFmpeg-devel] [PATCH] add av_shrink_packet
Thu Apr 9 00:20:21 CEST 2009
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
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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel