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

["Rémi Denis-Courmont" <remi@remlab.net>]

Le keskiviikkona 3. toukokuuta 2023, 22.05.26 EEST Michael Niedermayer a écrit 
:
> On Wed, May 03, 2023 at 07:07:09PM +0300, Rémi Denis-Courmont wrote:
> 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.

Well, the browser does not protect the user in that case. At best, an 
antimalware plugin or proxy might catch it but that's pretty much it. In fact, 
origin checks don't protect against this, nor are they intended to (AFAIK).

> > 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

User dialogues are notoriously bad for security purposes, as users don't 
really have the necessary info to make the proper decision, and just learn to 
click Allow Always. All they achieve is absolve the developers from protecting 
the user, really.

But even if, what will the criterion be? You'll match localhost. Okay. What 
about localhost.localdomain and 127.0.0.1? What about all the noncanonical 
writings of 127.0.0.1 and other addresses in 127.0.0.0/8, and their 
noncanonical writing? IPv6? What about the assigned external IP address of the 
host And so on, and that's just to prevent connections to localhost.

Some browsers prevent connections to private IP addresses too, to "protect" 
the Intranet, but the flip side is to break corporate content and home file 
servers.

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

I appreciate the thought but without a clearly defined threat model, you can't 
define the security issue, and thus you can't hope to fix it. Meanwhile, you 
will break things, and if you're not careful, you might as well make it easier 
for publishers to deliberately block FFmpeg.

> If you have a hls file that mixes local files and remote http(s) then you
> need to override the default protocol whitelist.

It makes sense for HLS manifests because HLS is by definition tied to HTTP, but 
that won't work for real playlists (M3U or other).

-- 
レミ・デニ-クールモン
http://www.remlab.net/



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