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

Baptiste Coudurier baptiste.coudurier
Wed Feb 27 14:02:40 CET 2008


Rich Felker wrote:
> On Wed, Feb 27, 2008 at 01:04:17PM +0100, Reimar D?ffinger wrote:
>> On Wed, Feb 27, 2008 at 12:52:54PM +0100, Reimar D?ffinger wrote:
>>> On Wed, Feb 27, 2008 at 12:33:08PM +0100, Baptiste Coudurier wrote:
>>>> Now Im curious, considering mov layout and libavformat mechanisms, what
>>>> would you expect to leak or read, besides what the user application is
>>>> allowed to read anyway (url_fopen suceeds), and what would be different
>>>> than garbage from a genuine self-contained file.
>>> Do you really not get the point?
>> Or alternatively, am I the only one who sees any of these points as really
>> _critical_? I am sorry if I annoy you because I am completely at odds
>> with your opinions, but to me this kind of behaviour feels just as bad
>> as any buffer overflow, and I can't help that it is considered a feature
>> just drives me crazy.
> 
> You're not the only one. I agree that this proposed patch and anything
> like it are utterly insane. lavf should deliver the embedded
> filename/url to the application as a custom stream or container
> metadata and leave the choice of what to do with it to the
> 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.

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

> The pay-per-byte internet access is also an extremely serious concern.

LOL.

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