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

[Michael Niedermayer <michael@niedermayer.cc>]

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

On Wed, May 03, 2023 at 07:07:09PM +0300, Rémi Denis-Courmont wrote:
> Le keskiviikkona 3. toukokuuta 2023, 16.33.59 EEST Michael Niedermayer a écrit 
> :
> > This patch was inspired by a report on ffmpeg-security about SSRF
> > (for which custom io_open() callback or soem sort of sandboxing/VM can be
> >  used to avoid it)
> >  The patch here was intended to explore if we can provide something thats
> >  better tahn currently by default
> 
> I am not sure how a dodgy HLS manifest would be any different from the user 
> clicking an hyperlink from a dodgy website - or opening a dodgy playlist file 
> in their FFmpeg-based media player application for that matter. Either way, it 
> can open any URL.

The difference is with a dodgy link its the web browser that has to protect
the user.
With a dodgy HLS file its ffmpeg that has to protect the user.


> 
> It is obviously not an ideal situation, but any restriction here will most 
> definitely break existing use cases (and likely be abused by server operators 
> to lock FFmpeg out).

My goal is to make it more secure by default and to keep it reasonable convenient
to the user

So to me at least, if i open an hls file and i get a popup asking me
"foobar.hls wants to access http://localhost/someexploit,"
"[Allow] [Deny] [Allow Always] [Deny Always]"
thats a win and i wouldnt call that "Breaking" an existing usecase.
Nor is that allowing any server operator to lock FFmpeg out

For a non GUI app thats a matter of adjusting the command line or defaults
by more classical means.

If we can make this more convenient to the user while keeping it secure we should. 
But we should not make it more convenient than what can be done securely.


> 
> Even the "obvious" blocking of secure (HTTPS) to nonsecure (HTTP) references 
> is likely to break stuff. If the end result is that everybody just turns origin 
> checking off, it's pretty pointless.
> 
> > But the same issue with roles flipped occurs for the end user and the user
> > cannot be expected to setup a custom io_open() callback for his player
> > The current code can be also used to poke
> > around the local network of the user. Which is unexpected by the user
> > for example a avi file could be probed as a m3u8 playlist and then
> > poke around on the local net while mixing that with remote urls
> > from the timing of the remote accesses the remote party should be able
> > to infer what happened with the local poking.
> 
> I agree, but it is unrealistic to change anything here. People make playlists 
> mixed with local files and network file systems or cloud storage services. Yes, 
> there is a slight information leakage. For instance, you can probe if a local 
> file exists by interleaving local and remote URLs in a playlist.

I dont know what software you are using but FFmpeg will prevent this attack
with default protocol whitelists

If you have a hls file that mixes local files and remote http(s) then you
need to override the default protocol whitelist.
If iam the user i would do that for that one file which in fact in that case
really has to be my file i wrote. Of course nothing stops the user to set that
by default for all urls, thats the users choice, but i think its much wiser not
to do that


thx

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

Elect your leaders based on what they did after the last election, not
based on what they say before an election.


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