On Wed, May 31, 2017 at 2:09 AM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > 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. >
Well, I want to be able to store a HLS playlist and its segments locally and play it, without specifying some obscure flag. So how can we make that work? In general, information disclosure is always a risk when you process unvalidated HLS streams, even if you load a remote http playlist which only contains HTTP links, it could reference something on your intranet and get access to something otherwise unavailable to the attacker. I would put the responsibility of ensuring this doesn't happen on people creating transcoding services, not making our protocols barely usable. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
