[FFmpeg-devel] [PATCH 3/4] avformat/concat: Add concat_enable option that is disable by default

[Andreas Cadhalpun]

On 21.01.2016 09:54, Nicolas George wrote:
> Le duodi 2 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
>> I think introducing protocol_whitelist could be a general solution.
>> It could have sensible defaults, e.g. if it is not passed as option
>> to avio_open2/ffurl_connect it could default to only local protocols
>> unless the protocol to open is a network protocol, in which case
>> it could default to only network protocols.
>>
>> So when opening 'file:', 'concat:' or other local protocol, the
>> protocol_whitelist would default to local protocols.
>> When opening 'http:', 'https:' or other network protocols, the
>> protocol_whitelist would default to network protocols.
>>
>> That should prevent mixing of local and remote data, unless
>> specifically requested by the API/CLI user.
>>
>> So if e.g. a local playlist 'file:' would contain 'http:' URLs a
>> protocol_whitelist allowing this combination would be required
>> for playback.
> 
> You have the right idea, but a simple white list of protocols is not enough.

At least it would go a long way in the right direction.

> If http://example.com/mostly_harmless.m3u pointing to
> file:///home/me/sensitive/file is a problem,

It's not necessarily a problem and when this is intended people could set
protocol_whitelist to 'http,file' and would be fine.

It becomes a problem if it is unintentional and typically, when opening a
local file, it is not intended that libavformat connects to the internet.
Likewise it is typically not intended that libavformat reads a local
file when given a network address.

> then we have exactly the same
> problem with it pointing http://intranet.local/sensitive/file,

For this to work an attacker would need to have knowledge about the
location of the sensitive file in the intranet, which is probably
more difficult to figure out than for local files, where standardized
locations for sensitive files like /etc/passwd exist.

> even more so
> if protocol options can turn it into a POST request.

As it is now, those protocol options would have to be set by the user,
and thus couldn't be easily exploited.

> If we want to take this issue seriously, we need a rather complex mechanism
> to ensure information separation, including same-origin policy and such.

A more complex mechanism would be more difficult to implement and also
more likely to contain bugs. So I suggest to focus on the less complex
protocol_whitelist approach first, which would guard against the majority
of potential problems in this area.
More complex mechanisms could be added on top later.

> Removing or disabling the concat protocol is like double-locking the door
> when the window is still wide open.

It certainly wouldn't be a general solution for this kind of problems.

Best regards,
Andreas