Re: [FFmpeg-devel] [PATCH] [RFC] avformat: Add basic same origin check

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] [RFC] avformat: Add basic same origin check
Date: Wed, 3 May 2023 21:08:42 +0200
Message-ID: <20230503190842.GF1391451@pb2> (raw)
In-Reply-To: <CA+anqdxbSyjer_5cCoGOoc48mS9GGMdt=-qenyeCpAhouz=sXg@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 2854 bytes --]

On Wed, May 03, 2023 at 02:24:34PM +0200, Hendrik Leppkes wrote:
> On Wed, May 3, 2023 at 12:49 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > On Wed, May 03, 2023 at 12:05:54PM +0200, Hendrik Leppkes wrote:
> > > On Tue, May 2, 2023 at 10:57 PM James Almer <jamrial@gmail.com> wrote:
> > > > >
> > > > > added
> > > > > +{"same_none"  , "same origin check off"                       , 0 , AV_OPT_TYPE_CONST, { .i64 = AVFMT_SAME_ORIGIN_CHECK_NONE }, 0, INT_MAX, D|E, "same_origin"},
> > > >
> > > > "none" sounds more natural.
> > > >
> > > > >
> > > > >
> > > > >> And do we want check_path to be default? It's a change
> > > > >> in behavior.
> > > > >
> > > > > is it usefull if its not enabled by default ?
> > > >
> > > > It is, since it can be enabled, like the whitelists and blacklists, but
> > > > the question is if it's preferable to have it enabled. If you consider
> > > > it so, then it's good and i wont oppose it.
> > > >
> > >
> > > Is there any estimation how many legitimate streams would be broken by
> > > these options?
> > > If any major streams don't work with this, then its not a good option,
> > > and eg. library users will likely just turn it off or to a lower
> > > setting, as proper streams just have to work - and log output is
> > > pretty much useless for API usage cases.
> > >
> > > A quick check for example shows that even something as simple as the
> > > HLS BBC Radio streams will fail _all_ checks, since the playlists are
> > > hosted on another host entirely as the media, thanks to akamai live
> > > streaming.
> > > Playlist here, as an example:
> > > http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/nonuk/sbr_low/ak/bbc_radio_one.m3u8
> >
> > yes, thats why it says RFC in the subject, i had expected that a bit already
> >
> > still OTOH, blocking these by default is the safer option, i mean if a user
> > does a
> > ./ffplay http://trustedfoobar.org/cutevideo.avi
> >
> > would she expect that video to access http://127.0.0.1/ and later http://evilhost/localwebscan-success
> > I think this should not be possible by default settings, its unexpected
> >
> 
> Coming from the other side -- If the user needs to set the flag for
> nearly all streams, then they are not going to check in the future and
> just set it, defeating the purpose of them. At which point we might as
> well not burden them.

Yes, we need a system that is secure and works in most cases.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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