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

[Reimar Döffinger]

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.
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).
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?