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

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Sat Jan 30 00:45:45 CET 2016


On 28.01.2016 20:16, Nicolas George wrote:
> Well, since we are sure there are more information leak issues in this area
> of code, we can still discuss a proper fix before the next one becomes
> public.
> 
> A few unsorted thoughts about it:
> 
> - Restrictions can not be limited to just the protocol, the host name, path,
>   etc., are important.

Granted, the protocol is not the only important information to decide what
could be an information leak and what not, but it can be used in libavformat
to give a default. I don't see how libavformat could do any sensible restrictions
based on host name or file path by default.

> - Applications need to be able to provide complex restrictions => a
>   callback is what we need.

OK, but this is somewhat orthogonal to libavformat preventing information leaks
by default. Also Anton has proposed a patch for something like that [1].
You might want to take a look at that.

> - Restrictions need to be pervasive, there must not be a code path that
>   discards them => attach them to the same data structures that allow
>   accessing dangerous resources: protocol implementations.

OK.

> - Global state is annoying for a library => take this occasion to get rid of
>   global state too.

I think this is a separate problem, not really related to information leaks.

> - If memory allocation is involved, failure is possible, checking is
>   annoying => design the code to be harmless and return immediately if the
>   structure are not correctly initialized. That way, only a final check is
>   needed.

OK.

> - Problem: the data structure belongs to what library? lavc? lavf?

If it is a generally useful structure it belongs into libavutil.

> => merge
>   the libraries so we do not have to worry about internal ABI compatibility.

I'm not sure that would be a good idea and anyway, this is another separate issue.

> Basically, the vague idea I have in mind would be a pervasive AVLibrary
> structure containing all the global state in the FFmpeg libraries: list of
> codecs, list of formats, list of protocols, lock manager,
> dynamically-computed tables, etc.

OK, that could solve the global state problem.

> And, of course, security policy.

I'm not sure what you mean with security policy here.

> Make it ref-counted, make it inheritable (avlib2 = avlib1 with an extra
> security restriction on top of it).

If it is global, why does it need to be ref-counted?

> As for the specific case of avoiding information leak, I suspect we need
> somehow to attach to any block of data (AVPacket, URL string, possibly
> option string) a structure describing where it came from and how trustworthy
> it is. But I have only a vague idea on how to do that.

Well, but that was the problem we originally wanted to solve...

It seems you primarily want to solve some other problems.

Best regards,
Andreas


1: https://lists.libav.org/pipermail/libav-devel/2016-January/074311.html



More information about the ffmpeg-devel mailing list