On 6/5/17, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Sat, Jun 03, 2017 at 09:20:04PM +0200, Michael Niedermayer wrote: >> This reduces the attack surface of local file-system >> 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. >> It does not stop leaks via remote addresses in the LAN. >> >> 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. There also where objections against >> restricting >> remote url file extensions. This here is a less robust but also lower >> inconvenience solution. >> It can be applied stand alone or together with other solutions. >> >> Found-by: Emil Lerner and Pavel Cheremushkin >> Reported-by: Thierry Foucu <tfo...@google.com> >> >> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> --- >> libavformat/hls.c | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) > > Applied with the author name joke suggested by nicolas
This is joke, please revert this. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
