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

[Rich Felker]

On Wed, Feb 27, 2008 at 04:02:35PM +0100, Baptiste Coudurier wrote:
> Rich Felker wrote:
> > On Wed, Feb 27, 2008 at 02:37:41PM +0100, Baptiste Coudurier wrote:
> >> Rich Felker wrote:
> >>> On Wed, Feb 27, 2008 at 02:02:40PM +0100, Baptiste Coudurier wrote:
> >>>>> application. Both url_fopen and callback are insane, especially if the
> >>>>> default callback is url_fopen in which case it is insecure by default.
> >>>> Nonsense due to the concept of the feature, patch welcome for callback.
> >>>>
> >>>>> I think Baptiste totally failed to understand the issue about
> >>>>> caller-registered url handlers which are common (e.g. mplayer always
> >>>>> uses one to connect to its own stream layer with cache)
> >>>> I understand the concerns, again callback patch welcome.
> >>> Callback is unwelcome. Read the end of the text you quoted (first
> >>> block). Putting the filename in metadata or somewhere else where the
> >>> application can read it and use it IF THE APPLICATION DESIRES TO is
> >>> the proper solution.
> >> Application has to USE A MOV DEMUXER to use external references, please
> >> read specs, understand.
> > 
> > I'm uninterested in Apple's ugly specs.
> 
> You have to follow specs if you want to deal with mov.

No, you have to be aware of them for certain things, but following
them is out of the question. For instance, files with incorrect
width/heigh stored in the container -- ffmpeg ignores this and uses
the full uncropped video size.

> Anyway I expect iso media to support external essences one day or another.

I really doubt this since it's idiotic and iso media probably has no
sense of a filesystem, much less the idiotic Macintosh semantics in
the QT spec.

> > FFmpeg's role is to implement
> > clean demuxers and decoders in a uniform way, not to follow Apple's
> > idea of what a "QuickTime application" should do. If someone is
> > writing an application and wants to follow that, it's their job to use
> > the FFmpeg libs in the appropriate way to get the desired behavior.
> 
> No, goal of FFmpeg is to support the more possible files in a reasonable
> way, some already existing hacks are not clean.
> There is a feature, it is documented in some way.
> I really hate being forced to use Quicktime to play such files.
> I clearly agree with Michael saying that if we would follow your opinion
> we would only play 30% of existing files, this is not acceptable.

Just rm the stupid file with the 'external essence' reference in it
and play the separate file that it points to. Problem solved.

> >> and not including them in svn.
> >> This by no means is a guarantee to be safe within your URLProtocol code,
> >> if you used register_protocol, one user could still very well exploit
> >> your code with commandline, and API, giving deliberatly wrong args.
> > 
> > Nonsense. In such applications, the ONLY urls ever used are the
> > custom-registered ones, and the string comes only from the caller who
> > generated the token (likely an address) to link the url to the
> > caller's stream object. There is absolutely no way for any url except
> > these (which all come from a trusted source) to be passed to
> > url_fopen, until you start doing IDIOTIC things like your patch.
> 
> Nonsense, how many applications did you check before saying this ?
> How can you be so sure about how users can tweak and use
> ffmpeg/libavformat ?

I don't need to check apps because any app that uses both ALREADY has
significant robustness/security issues. Your code only adds a new vuln
in apps that are doing the correct behavior I described.

> I can perfectly imagine that some people have custom URLProtocols and
> they plugged it into a custom ffmpeg binary, and using
> av_open_input_file in some cases and av_open_input_stream in other
> cases. It is technically possible.

And positively vulnerable.

Rich