[FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Mon Jan 25 23:30:04 CET 2016


On 24.01.2016 21:32, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
>> No. It would have prevented the issue with hls.
> 
> Reacting to known attacks by ad-hoc hole-plugging is no way of building
> proper security.

The ad-hoc fix was the change done in the hls demuxer.
The protocol_whitelist approach would prevent this class of issues, while
being a rather simple mechanism that could be implemented in a backwards
compatible way for almost all usecases.

>> But it's usually only used with local files.
> 
> I do not know that. Do you?

I suspect it. For instance that's the example in the documentation.
And it should less dangerous restricting the concat protocol to handling
of local files by default.

>> Why not?
> 
> Because remote files can be more sensitive than local ones.

It's not possible for libavformat to know what is sensitive and what not.
But sending local files to remote is definitely problematic, when it
happens unintentionally.
Even just accessing a remote site when opening a local file can be
considered a privacy breach.

> Because some environment may download files, turning remote to local.

I don't see how that is a problem.

>> How?
> 
> I do not know,

Then you shouldn't have claimed it would be insecure.

> but you can assume that someone knows and is selling that
> information to the highest bidder.

That can be said about any approach and it's not possible to prove it right
or wrong. Thus stating this is completely pointless.

> We know that playlists can be abused to leak information. Reimar was warning
> about it years ago. People implemented them nonetheless, and guess what, it
> did cause information leak.
> 
> Now, your reaction is among the lines "the burglar left a footprint in front
> of that window, let us wall it".

Using this metaphor I would describe the situation differently:
"The burglar knocked on the window and an unsuspecting person, let's call him
Henry Louis Simplex, opened it for him. The quick fix for preventing this
from happening again is to tell H.L.S. not to open that window.
A better fix is to lock all windows so that people can only open windows
they have a key for (i.e. which are on the whitelist)."

> I say no, walling is overkill, and walling only that particular window is useless.

I don't know why you say 'walling', which would mean it's impossible to ever get
through.  However, with the right keys/whitelist one could still open any desired
combination of windows/protocols.

> We need to properly lock all the windows.

That's exactly what the protocol_whitelist approach would do.

You seem to be aiming for a complex mechanism of enforcing a security policy,
which would require fundamental API changes.
But there haven't been many details about how you envision the security policy,
or how it could be implemented. Maybe you can add some more about this?

In any case, the more complex a solution is, the more likely is it to
contain bugs.

Best regards,
Andreas


More information about the ffmpeg-devel mailing list