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

[Baptiste Coudurier]

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.
Anyway I expect iso media to support external essences one day or another.

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

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

It is easiest and simplest solution.

>> 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 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.
Look at the email in -devel talking about dealing with subtitles in
demuxers.

>>>>> The pay-per-byte internet access is also an extremely serious concern.
>>>> LOL.
>>> ???
>> Yes, LOL.
> 
> Go ()#$* yourself. I hate snobby attitudes like this.
> 

Is it really "D Richard Felker III" saying this ?

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