On 01.06.2017 13:44, Michael Niedermayer 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>
Fix inspired by: Tobias Rapp <t.r...@noa-archive.com>
Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
---
libavformat/options_table.h | 2 +-
libavformat/utils.c | 6 +++++-
tests/fate/avformat.mak | 4 ++--
tests/fate/filter-audio.mak | 4 ++--
4 files changed, 10 insertions(+), 6 deletions(-)
[...]
I would prefer this patch over the one in
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211796.html
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
