On Fri, Jun 02, 2017 at 09:27:16PM +0200, Hendrik Leppkes wrote: > On Fri, Jun 2, 2017 at 9:19 PM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > This reduces the attack surface of local file-system and local network > > information leaking. > > > > It prevents the existing exploit leading to an information leak. As > > well as similar hypothetical attacks. > > > > Leaks of information from files and symlinks ending in common multimedia > > extensions > > are still possible. But files with sensitive information like private keys > > and passwords > > generally do not use common multimedia filename extensions. > > > > 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. > > > > Developers have expressed their dislike / objected to disabling hls by > > default as well > > as disabling hls with local files. This here is a less robust but also lower > > inconvenience solution. > > It can be applied stand alone or together with other solutions. > > > > One of the most important things is that at the very least HLS keeps > working out of the box without magic options for actual HTTP HLS > streams, ie. their primary domain. > One aspect of this is that HLS streams hosted by CDNs often don't have > an actual extension, since they get generated by various dynamic URLs, > and this would break that, so its not a good idea.
please provide an example that fails with the patch > > No matter what security fixes get applied, if HLS basically stops > working its basic functionality, then its going too far. > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
