On Wed, 31 May 2017 11:29:56 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Wed, May 31, 2017 at 09:03:34AM +0200, Hendrik Leppkes wrote: > > 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? > > What you ask for is to use vulnerable code (hls with local files is > pretty much vulnerable by design). > Enabling this by default is a bad idea and it would be also an > exception to how its handled in other demuxers. > For example mov has drefs disabled without the enable_drefs flag. > > Other means than a flag could be used to let the user enable it. > Would this be what you had in mind ? If so what did you had in mind > exactly ? > > > > > > 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. > > According to the authors of the exploit, which they kindly seem to > have sent to every affected company but not to us. > Most if not all the big names had hls enabled and were vulnerable. > So "its the users responsibility" alone did clearly not lead to secure > code. > > Also users cannot review the ever growing feature set we have for > security sensitive features and disable them, thats not practical nor > would it be reasonable from us to ask them to do that. > > If you see a better solution than to disable hls or local file use in > hls by default then please explain what you suggest ? How is this "vulnerable"? If it's via the completely useless and annoying bullshit tty decoder, I'm going to throw a party. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel