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

Rich Felker dalias
Wed Feb 27 15:43:05 CET 2008


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

> >>> and how the
> >>> existing API does not require them to be 'secure' against malicious
> >>> urls. For instance, my://0x12345678 (where the number is a pointer)
> >>> might be valid and the registered url handler might use data stored at
> >>> 0x12345678 to determine addresses to perform writes to. Thus, if a
> >>> file can cause an arbitrary address to be passed after my://, there is
> >>> surely a privilege elevation vulnerability.
> >> Seriously 1) Read code 2) Read specs.
> >> Demuxer is reading data through ByteIOContext, if you do insane and ugly
> >> things with your URLProtocol, well....
> > 
> > This is not insane and ugly; it's the intended use of URLProtocol for
> > applications that have their own stream layers. This sort of practice
> > has been recommended MANY times on the list in the past, so going back
> > and suddenly making it insecure and deprecated is unacceptable.
> 
> You are messing everything up.
> 
> No, suggestions were to use custom URLProtocol for ugly and insane
> practices (like the one you suggested),

How is this ugly or insane? IMO the inclusion of
stream-layer/url_fopen in libavformat is what's insane. A sane API
would have the caller pass a stream object rather than a string when
opening a demuxer.

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

> >>> The pay-per-byte internet access is also an extremely serious concern.
> >> LOL.
> > 
> > ???
> 
> Yes, LOL.

Go ()#$* yourself. I hate snobby attitudes like this.

Rich




More information about the ffmpeg-cvslog mailing list