Re: [FFmpeg-devel] [PATCH 2/3] avformat/imfdec: fail on probing non xml file extension

[Pierre-Anthony Lemieux <pal@sandflow.com>]

On Mon, May 8, 2023 at 3:01 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Mon, May 08, 2023 at 11:40:49AM -0700, Pierre-Anthony Lemieux wrote:
> > On Mon, May 8, 2023 at 11:23 AM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > > On Sun, May 07, 2023 at 10:09:58PM -0700, Pierre-Anthony Lemieux wrote:
> > > > On Sun, May 7, 2023 at 12:18 PM Michael Niedermayer
> > > > <michael@niedermayer.cc> wrote:
> > > > >
> > > > > On Sat, May 06, 2023 at 11:01:20AM -0700, Pierre-Anthony Lemieux wrote:
> > > > > > On Sat, May 6, 2023 at 6:25 AM Michael Niedermayer
> > > > > > <michael@niedermayer.cc> wrote:
> > > > > > >
> > > > > > > Its unexpected that a .avi or other "standard" file turns into a playlist.
> > > > > > > The goal of this patch is to avoid this unexpected behavior and possible
> > > > > > > privacy or security differences.
> > > > > >
> > > > > > Per the IMF specification, a CPL can have any extension or, in fact,
> > > > > > no extension. The latter is routinely used.
> > > > >
> > > > > is there a restriction on the URL/URIs used in it ?
> > > > > that is in practice, can they be restricted to the same server,
> > > > > child directories, or some other restriction ?
> > > >
> > > > Below is a brief overview of the linkage between the various of
> > > > components of an IMF composition:
> > > >
> > > > - the Composition Playlist (CPL) is the file that is passed to FFMPEG
> > > > as input (-i)
> > > > - the CPL is an XML document and defines a playlist
> > > > - each of the components that make up the playlist is identified by a
> > > > UUID, i.e. the CPL does not contain file paths/URLs.
> > > > - the mapping between UUIDs and URLs is done through separate XML
> > > > files called Asset Maps. Paths to Asset Maps can be provided
> > > > explicitly through the "-assetmaps" argument, otherwise FFMPEG looks
> > > > for a file called "ASSETMAP.xml" in the same directory as the CPL
> > > > file.
> > > > - according to the standard, all URLs in each Asset Map is relative to
> > > > the location of the Asset Map, and thus the CPL and the Asset Map have
> > > > the same origin
> > > > - some applications have relaxed this constraint and allowed absolute
> > > > URLs in the Asset Map
> > >
> > > Thank you for this information
> > >
> > >
> > > >
> > > > What is the threat scenario? Is the concern that a malicious actor
> > > > provides a CPL and Asset Map from origin A that makes malicious
> > > > requests to a different origin B?
> > >
> > > I do not have an exhaustive list of what can be done, but ill list a
> > > few things i can think of with some random ideas.
> > >
> > > First if i pretend to be the attacker, i want one file not 2 because
> > > thats easier
> > > can i just send the victim a ASSETMAP.xml that parses correctly as
> > > CPL too ?
> >
> > Both ASSETMAP.xml and CPL are XML files. The root element of the
> > former is "AssetMap" and the root element of the latter is
> > "CompositionPlaylist".
> > The IMF demuxer fails if this is not true, so an Asset Map document
> > cannot be mistaken for a CPL, and vice-versa.
>
> That is good
>
>
> >
> > > If yes, i think that can be checked for and trigger an error because
> > > i dont think a valid file would use itself as assetmap
> > > we could go a bit further here and play with things like
> > > ASSETMAP.xml?video.avi
> > > or something like that to make the link look more normal
> > > i didint look at if that would work but it just makes it more harmless looking
> > >
> > > now what can one do with this
> > >
> > > A Spying
> > > 1. User downloads a video file
> > > now every time she plays the file, the file pings a URL revealing time, frequency and IP of the watched file
> > > This is probably not expected by the user
> > >
> > > B1 Poking
> > > 1. User downloads or plays a video file
> > > now the file refers to various urls testing the users local network and network services
> > > timing of remote accesses reveals this to an attacker
> > > This is probably not expected by the user either
> > >
> > > B2 same as B1 but a attacker uploads the file to a server where the attacker pokes around using it
> > >
> > > B3 the URL requests to other services may or may not be able to do more than just reading
> > >
> > > C DOS
> > > a attacker uploads a file with many references and lets the server repeatly attempt connections
> > > to them
> > > This one is tricky because we liekly want to continue if one reference fails
> > > but also not do thousands of odd accesses to anything
> > >
> > > This could plausibly even be used to bruteforcing some auth parameters
> > > upload a file with all 4 digit pin codes in their URL and then depending on
> > > what is encoding, maybe what length the resulting encoded file has one could
> > > maybe figure out which URL access succeeded.
> > >
> > > Iam not an expert in this so quite likely theres more that can be done that
> > > iam not thinking of
> > >
> > > Thus anything that isnt part of normal use cases, i suggest to not allow by default
> > > (like for example a ASSETMAP.xml thats also a valid CPL file)
> >
> > The scenarios above require FFMPEG to access URLs outside of the
> > origin of the CPL and ASSETMAP. Would implementing a same-origin
> > policy help?
>
> yes, i belive this would significantly reduce what an attacker can do
> with this

Is there a general concept of "same-origin" in FFMPEG?

>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you fake or manipulate statistics in a paper in physics you will never
> get a job again.
> If you fake or manipulate statistics in a paper in medicin you will get
> a job for life at the pharma industry.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".