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

[Anton Khirnov]

Quoting Pierre-Anthony Lemieux (2021-12-14 17:52:48)
> On Tue, Dec 14, 2021 at 2:31 AM Anton Khirnov <anton at khirnov.net> wrote:
> >
> > Quoting pal at sandflow.com (2021-12-13 06:43:35)
> > > From: Pierre-Anthony Lemieux <pal at palemieux.com>
> > >
> > > Signed-off-by: Pierre-Anthony Lemieux <pal at palemieux.com>
> > > ---
> > >
> > > Notes:
> > >     The IMF demuxer accepts as input an IMF CPL. The assets referenced by the CPL can be
> > >     contained in multiple deliveries, each defined by an ASSETMAP file:
> > >
> > >     ffmpeg -assetmaps <path of ASSETMAP1>,<path of ASSETMAP>,... -i <path of CPL>
> > >
> > >     If -assetmaps is not specified, FFMPEG looks for a file called ASSETMAP.xml in the same directory as the CPL.
> > >
> > >     EXAMPLE:
> > >         ffmpeg -i http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml out.mp4
> > >
> > >     The Interoperable Master Format (IMF) is a file-based media format for the
> > >     delivery and storage of professional audio-visual masters.
> > >     An IMF Composition consists of an XML playlist (the Composition Playlist)
> > >     and a collection of MXF files (the Track Files). The Composition Playlist (CPL)
> >
> > As far as I can tell, nothing enforces that the files opened are
> > actually MXF. Perhaps that should be done. Otherwise I can imagine at
> > least the danger of recursion.
> 
> Addressed by v11 of the patchset.
> 
> Track Files are now constrained to "mxf".
> 
> >
> > More generally, I am somewhat concerned about the security implications
> > of all this. From a brief glance at the patch, the demuxer just opens
> > whatever arbitrary URLs it finds in the asset maps. Have you considered
> > what undesirable effects (like information leaks) this might have?
> 
> The ASSETMAP file, where the demuxer finds the URLs of the Track
> Files, is an integral part of an IMF delivery and is assumed to be
> trusted. This is typically achieved by retrieving the ASSETMAP over a
> trusted channel, e.g. HTTPS to a trusted server or on a trusted local
> drive, etc.

I don't think you can just assume that much, since libavformat is
commonly used with untrusted input. It's good that at least the assetmap
file path is not specified in the main CPL file, but I can still imagine
a situation where the user somehow receives a directory with a
CPL+ASSETMAP.xml from an untrusted source and tries to open it e.g. in
VLC.

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?

-- 
Anton Khirnov