On Sat, Jun 3, 2017 at 2:58 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Sat, Jun 03, 2017 at 11:18:46AM +0200, Hendrik Leppkes wrote: >> On Sat, Jun 3, 2017 at 2:31 AM, Michael Niedermayer >> <mich...@niedermayer.cc> wrote: >> > 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 >> > >> > >> >> I couldn't find a public HLS stream right away that uses no >> extensions, but I do know that they exist and its easy to craft one >> just by renaming the segments and editing the playlist - I had issues >> with this in an Android app I was working on last year. > > Do you object to fixing this security issue that has a working exploit? > Can you provide a testcase the fix breaks ? So i can look into what > can be done about it ? (multiple testcases would be even better so > theres a lower chance of breaking things) > >
I object to breaking a functioning protocol in the name of some obscure social-engineering attack. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
