[FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default

[Hendrik Leppkes]

On Wed, May 31, 2017 at 2:09 AM, Michael Niedermayer
<michael at 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
>> <michael at 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 <tfoucu at 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?

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.

- Hendrik