[FFmpeg-cvslog] r12241 - trunk/libavformat/mov.c

[Baptiste Coudurier]

Reimar D?ffinger wrote:
> On Wed, Feb 27, 2008 at 11:18:41AM +0100, Baptiste Coudurier wrote:
>> If providing a cb is only to let user application call url_fopen to get
>> ByteIOContext this is clearly useless, furthermore when libavformat
>> already uses url_fopen to open the reference file path given by the user
>> application.
> 
> No, the cb is to let the user application do filtering (and also just
> disable the feature if it does not want to bother with it).
> By using url_fopen _directly_ this means that the mov demuxer can access
> any resource that has a stream layer implemented.
> This means local file can access network streams (may be used to spy on
> the user).
> This means remote files can access local files (DVD drive, TV card)
> which can at least create confusion for the user.
> This means remote files can access custom protocols registered with
> libavformat by the main application. This includes protocols that
> directly access e.g. shared memory and never were designed to be secure
> against remote access to them.

All the features you decribes are supported by Quicktime player, and
I'll do as much as I can to support them in a reasonable way. I consider
this reasonable.

Now Im curious, considering mov layout and libavformat mechanisms, what
would you expect to leak or read, besides what the user application is
allowed to read anyway (url_fopen suceeds), and what would be different
than garbage from a genuine self-contained file.

Btw, external elementary streams are pretty common in my hands.

> And since using the latter kind of protocols was publicly suggested
> here, I actually even think that this change (a demuxer using url_fopen)
> even constitutes an API change, since it completely changes the rules
> for the stream layer (formerly the streams opened were completely under
> the control of the application, so in some cases handling of URL-strings
> were irrelevant to security, but now they suddenly this is a part that
> is _critical_ to security).

Security is really important, yes.
I understand your concerns though, and if you want to supply a patch
adding a callback to open external resources I think I'll be ok with it,
but if no callback is provided, I'll fallback on url_fopen.

> In addition the patch assumes that the URL syntax used by the MOV
> specification is the same as the one used by FFmpeg. I am not sure about
> this, e.g. how is e.g. a rtsp:// reference supposed to be handled inside MOV?

Need to check specs I guess, code is only handling Alias Record.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312