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

[Tobias Rapp]

On 31.05.2017 18:33, Michael Niedermayer wrote:
> On Wed, May 31, 2017 at 05:18:57PM +0200, Tobias Rapp wrote:
>> On 31.05.2017 15:42, wm4 wrote:
>>> On Wed, 31 May 2017 14:49:19 +0200
>>> Michael Niedermayer <michael at niedermayer.cc> wrote:
>>>
>>>> [...]
>>>>
>>>> Security fixes should be as simple as
>>>>   possible.
>>>
>>> Well, your fix isn't simple. It adds yet another exception with
>>> questionable effect. It makes it more complex and harder to predict
>>> what will actually happen, not simpler.
>>>
>>>> If people want, I can limit the local file check to the case where
>>>> the io_open callback is not set?
>>>> That way user applications which do their own sanitation would not be
>>>> affected by the check or error message and stay in full control of
>>>> what access is allowed.
>>>
>>> That would have little value and would make it more complex too.
>>>
>>> I'd say a good way to make this secure would be disabling the hls
>>> protocol in builds which are security sensitive.
>>
>> We already have "protocol_whitelist", --disable-protocol and
>> application sandboxing as supported and generic options. I agree
>> with wm4 that some special case-handling here just adds complexity.
>
> "--disable-protocol" does not allow fixing this, the vulnerability
> only needs the file protocol ultimatly.
>
> similarly protocol_whitelist only helps if "file" is not on it,
> no other protocol is really required for this.
>
> I just confirmed the exploit works with
> -protocol_whitelist file,crypto
>
> sandboxing is the awnser for automated transcoding services but
> the average joe end user cannot use sandboxing
>
> What do you suggest ?

Well as far as I understand the user must
(a1) be tricked into opening a playlist file with FFmpeg
or
(a2) some software based on FFmpeg libraries, then
(b) be tricked into uploading the output file to a server under control 
of the attacker.

Adding another command-line argument will not help much for (a1) as user 
Joe Average might not find/understand it in the long list of options (or 
the options are simply hidden behind some script - but in case a script 
is executed we have lost already anyway).

For (a2) the application should put playlist muxers on the blacklist, if 
not required for normal usage. When being extra cautious this could be 
the library option's default.

Now (b) is the biggest part of the security breach. Uploading 
non-verified binary data to unknown third parties is bad. Thats the 
reason why Joe Average should also opt-out to all that telemetry or 
crash report uploading done by other applications.

But if Joe is willing to upload some data which has been generated via 
some untrusted commands he is not far from uploading other readable 
local files anyway - I see no meaningful way to prevent that from code 
within FFmpeg.

Regards,
Tobias