[FFmpeg-devel] [PATCH] avformat/hls: Check file extensions

[Hendrik Leppkes]

On Sat, Jun 3, 2017 at 2:58 PM, Michael Niedermayer
<michael at 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
>> <michael at 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
>> >> <michael at 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