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? - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
