On Wed, May 31, 2017 at 01:14:58AM +0200, Hendrik Leppkes wrote: > On Wed, May 31, 2017 at 12:52 AM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > This prevents an exploit leading to an information leak > > > > The existing exploit depends on a specific decoder as well. > > It does appear though that the exploit should be possible with any decoder. > > The problem is that as long as sensitive information gets into the decoder, > > the output of the decoder becomes sensitive as well. > > The only obvious solution is to prevent access to sensitive information. Or > > to > > disable hls or possibly some of its feature. More complex solutions like > > checking the path to limit access to only subdirectories of the hls path may > > work as an alternative. But such solutions are fragile and tricky to > > implement > > portably and would not stop every possible attack nor would they work with > > all > > valid hls files. > > > > Found-by: Emil Lerner and Pavel Cheremushkin > > Reported-by: Thierry Foucu <tfo...@google.com> > > > > >
> I don't particularly like this. Being able to dump a HLS stream (ie. > all its file) onto disk and simply open it again is a good thing. > Maybe it should just be smarter and only allow using the same protocol > for the segments then it already used for the m3u8 file, so that a > local m3u8 allows opening a local file (plus http(s), in case I only > saved the playlist), but a http HLS playlist only allows http > segments? we already prevent every protocol except file and crypto for local hls files. We also already block http* in local hls files by default thorugh default whitelists (file,crypto for local files) This is not sufficient, the exploit there is successfully puts the content of a readable file choosen by the attacker into the output video, which if its given back to the attacker leaks this information. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
