On 12/25/18, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Mon, Dec 24, 2018 at 11:54:31PM +0000, Kieran Kunhya wrote: >> > >> > commit 0ca7a8deeffd33e05ae15a447259b32b6678c727 (HEAD -> master) >> > Author: Michael Niedermayer <mich...@niedermayer.cc> >> > Date: Mon Dec 24 01:14:50 2018 +0100 >> > >> > avcodec/lagarith: Optimize case with singleton probability >> > distribution >> > >> > Fixes: Timeout >> > Fixes: >> > 10554/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5739938067251200 >> > >> > In case of a Denial of Service attack, the attacker wants to >> > maximize >> > the load on the target >> > per byte transmitted from the attacker. >> > For such a DoS attack it is best for the attacker to setup the >> > probabilities so that the >> > arithmetic decoder does not advance in the bytestream that way the >> > attacker only needs to >> > transmit the initial bytes and header for an arbitrary large frame. >> > This patch here optimizes this codepath and avoids executing the >> > arithmetic decoder more than >> > once. It thus reduces the load causes by this codepath on the >> > target. >> > We also could completely disallow this codepath but it appears such >> > odd probability >> > distributions are not invalid. >> > >> > Found-by: continuous fuzzing process >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> > >> >> This is a nonsense argument, a user could send a frame that was >> 99999999x99999999 in dimensions, would have the same effect. > > This suggested attack would not work, a user wanting to minimize these > DoS issues would have set AVCodecContext.max_pixels which would block this. > > >> The calling application should manage timeouts themselves in a sandbox or >> container or similar. > > Its always possible and also a very good idea to have a 2nd line of defense > like a sandbox / VM, ... as you suggest here, I did and do agree here. > And also a 3rd line of defense, ... > > But this doesnt mean we should not attempt to fix or mitigate > security (or other) issues directly in the code. > > I think the point you are raising has been raised previously, so let me > argue a little broader here and not specific to just what you suggest. > > If you compare a native fix in the code with a fix by a timeout, a > fix by a timeout causes: > * The whole process to be killed, so any application using libavcodec > would basically "crash" and would not neccessarily save its state, > flush out buffers, write any trailers or do proper protocol shutdowns > or save any unsafed data. This is a outcome that should be minimized > * Using a timeout as the main way to block DoS is difficult as there is > often no good timeout value. Its not unexpected that a system may need to > support processing large videos taking several hours, thats a long > time for a file of a hundread bytes in a DoS attack > 100bytes from an attacker could cause the same load as 1000000000 bytes > from > a user. > * Worst maybe is that a tight timeout likely makes the system more > vulnerable > not less. because during an attack all the processes would likely slow > down and real users would be pushed into the timeout even if the system > without the user processes timeouting would still function correctly > > Iam sure there are more arguments but above are the ones that came to my > mind > ATM. > >> >> Merry Xmas. > > Merry Xmas as well! > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin >
This is still missing numbers/statistics. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
