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

Baptiste Coudurier baptiste.coudurier
Wed Feb 27 16:44:46 CET 2008


Rich Felker wrote:
> 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.

Again this a feature, FFmpeg interpreting values or wanting every
formats values and concepts to fit in a constrained API is hard,
sometimes not right.

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

Not the Macintosh alias record, but external essences is definitely
wanted/needed, and definitely you are clueless: Section 8.13 of 14496-12:

The data reference object contains a table of data references (normally
URLs) that declare the location(s) of
the media data used within the presentation. The data reference index in
the sample description ties entries in
this table to the samples in the track. A track may be split over
several sources in this way.

[...]

aligned(8) class DataEntryUrlBox (bit(24) flags)
   extends FullBox(`url ', version = 0, flags) {
   string   location;
}

aligned(8) class DataEntryUrnBox (bit(24) flags)
   extends FullBox(`urn ', version = 0, flags) {
   string   name;
   string   location;
}

Please don't waste the time I could use to add more features to FFmpeg.

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

No, again you need a MOV demuxer to play external essences correctly.

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

Where ? Did you read code correctly ? there cannot be any ':' in the arg
supplied to url_fopen....

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

They can shoot themselves in the foot.

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




More information about the ffmpeg-cvslog mailing list