From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 2DF5345CDF for ; Wed, 3 May 2023 19:05:39 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AB7A968BEBB; Wed, 3 May 2023 22:05:35 +0300 (EEST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9BAEF68AEB3 for ; Wed, 3 May 2023 22:05:29 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 805DCC0006 for ; Wed, 3 May 2023 19:05:28 +0000 (UTC) Date: Wed, 3 May 2023 21:05:26 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230503190526.GE1391451@pb2> References: <20230502193631.10844-1-michael@niedermayer.cc> <09C1198A-DB0A-43CC-ADCA-23594E0BFEDA@remlab.net> <20230503133359.GD1391451@pb2> <1846772.vxqQoQgO3c@basile.remlab.net> MIME-Version: 1.0 In-Reply-To: <1846772.vxqQoQgO3c@basile.remlab.net> Subject: Re: [FFmpeg-devel] [PATCH] [RFC] avformat: Add basic same origin check X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============2360681272961118707==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2360681272961118707== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BQPnanjtCNWHyqYD" Content-Disposition: inline --BQPnanjtCNWHyqYD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 03, 2023 at 07:07:09PM +0300, R=E9mi Denis-Courmont wrote: > Le keskiviikkona 3. toukokuuta 2023, 16.33.59 EEST Michael Niedermayer a = =E9crit=20 > : > > 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 tha= ts > > better tahn currently by default >=20 > I am not sure how a dodgy HLS manifest would be any different from the us= er=20 > clicking an hyperlink from a dodgy website - or opening a dodgy playlist = file=20 > in their FFmpeg-based media player application for that matter. Either wa= y, it=20 > 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. >=20 > It is obviously not an ideal situation, but any restriction here will mos= t=20 > definitely break existing use cases (and likely be abused by server opera= tors=20 > to lock FFmpeg out). My goal is to make it more secure by default and to keep it reasonable conv= enient 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.=20 But we should not make it more convenient than what can be done securely. >=20 > Even the "obvious" blocking of secure (HTTPS) to nonsecure (HTTP) referen= ces=20 > is likely to break stuff. If the end result is that everybody just turns = origin=20 > checking off, it's pretty pointless. >=20 > > But the same issue with roles flipped occurs for the end user and the u= ser > > 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. >=20 > I agree, but it is unrealistic to change anything here. People make playl= ists=20 > mixed with local files and network file systems or cloud storage services= =2E Yes,=20 > there is a slight information leakage. For instance, you can probe if a l= ocal=20 > 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 t= hat by default for all urls, thats the users choice, but i think its much wiser= not to do that thx [...] --=20 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. --BQPnanjtCNWHyqYD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZFKwcQAKCRBhHseHBAsP q81eAJ0cY3BeqCHjF5XioUtQLXsw3EiJcwCeKNR9+Sg7f6urfVShhFcUVPqonhw= =k9Jz -----END PGP SIGNATURE----- --BQPnanjtCNWHyqYD-- --===============2360681272961118707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============2360681272961118707==--