[FFmpeg-devel] [PATCH v10 1/2] avformat/imf: Demuxer

Anton Khirnov anton at khirnov.net
Wed Dec 15 22:20:25 EET 2021


Quoting Pierre-Anthony Lemieux (2021-12-15 01:17:26)
> >
> > Now the question is whether a malicious attacker can craft those two
> > files to get access to anything they shouldn't. I suppose at the very
> > least the attacker can get information that the user opened the file (by
> > adding an asset on an attacker's server) but that will be a danger with
> > any playlists allowing network resources and can be controlled with
> > io_open(). Can you think of any other possible issues?
> >
> 
> Some security considerations:
> 
> - a DDoS can conceivably occur if a malicious CPL+ASSETMAP is widely
> distributed. Both an ASSETMAP and a CPL are required since (a) the CPL
> does not contain paths/hyperlinks and (b) only those resources
> referenced by the CPL are fetched using the ASSETMAP.
> - the CPL uses XML, which has its own security considerations. For
> example, XML parsing can result in entities being fetched over the
> network, but this is disabled by default in libxml AFAIK.

This is concerning. From a brief glance at libxml2, it seems that you
need to pass XML_PARSE_NONET as the last parameter to xmlReadMemory() to
actually disabling network fetching.
But it is possible I'm misreading the code, so if you or anyone else
understands this better then clarifications are welcome.

> - several elements/attributes of the IMF CPL use URIs as unique
> identifiers. These URIs could conceivably be dereferenced.
> Dereferencing these URIs is however not a requirement and the IMF
> demuxer does not do so.
> - IMF only uses MXF to wrap essence but supports various kinds of
> essence, e.g. Prores and J2K, each with its own security
> considerations

The demuxer should not be concerned about what the user does with the
returned data. Only the behavior of the demuxer itself (and whatever
code it calls) is the question here.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list