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 ESMTPS id 3F0EA49B1E for ; Tue, 28 Jan 2025 21:44:36 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0B5DA68BAD0; Tue, 28 Jan 2025 23:44:33 +0200 (EET) Received: from mslow3.mail.gandi.net (mslow3.mail.gandi.net [217.70.178.249]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C078B68A4FA for ; Tue, 28 Jan 2025 23:44:26 +0200 (EET) Received: from relay0.mail.gandi.net (relay0.mail.gandi.net [217.70.178.220]) by mslow3.mail.gandi.net (Postfix) with ESMTP id 24837580DA7 for ; Tue, 28 Jan 2025 21:44:26 +0000 (UTC) Received: by mail.gandi.net (Postfix) with ESMTPSA id E5F0944122 for ; Tue, 28 Jan 2025 21:44:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1738100660; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YHDCsOKGY9HQ1XmOscXMwHEuEFNJIIlgiI9wcoO5sZs=; b=HzBLWd2ZzeW28NAfTlRDy4r7cOF7YFNlWS49HN/9nHkGGeAY8mCZ4+lWDD6GmuebLcoR/W nsafZ9o3tmp3DO+JU/yqOZpOqtpbJ1EAupoljUD+O73k7a8eFW+nZ6+FxrwjKLMH7V9RBr wk+uHZ6cY7gtl3NjFLEonPBVt8iIlWA/d7UsgfaODfz/NrJSlmEAciVcN0pHCBX5tmrQla D3S8SEnsBkj1EYTez4KUQ+qGLMAAxfXAOcFjeoLq6oPl9lHvBLDV84NyVL6DwYYGVRrkVz 2t0p9S1cpJZTaAO/5q7lICN2rnBHnsTi+eySlxUD/SohUWu2kj0HGRLjl1cPwg== Date: Tue, 28 Jan 2025 22:44:18 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250128214418.GY4991@pb2> References: <20250128142421.337241-1-michael@niedermayer.cc> <20250128142421.337241-2-michael@niedermayer.cc> MIME-Version: 1.0 In-Reply-To: X-GND-State: clean X-GND-Score: -85 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdduhedmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeefhedugefhvdektddvtddvfeejgeeltdegveffteejvdfhkeetkefhhfdttedtudenucffohhmrghinhepfihikhhiphgvughirgdrohhrghenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4 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="===============2164219740758685256==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2164219740758685256== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ukSlNzvSBmt9lNW2" Content-Disposition: inline --ukSlNzvSBmt9lNW2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Tue, Jan 28, 2025 at 10:12:30PM +0200, Jan Ekstr=C3=B6m wrote: > On Tue, Jan 28, 2025 at 4:24=E2=80=AFPM Michael Niedermayer > wrote: > > > > Maybe fixes: 11435 > > >=20 > Do I understand correctly that the root issue that's being attempted > to be fixed by the initial patch set is that unusual demuxers were > possible to have been probed and opened through the HLS meta demuxer? > In that case I would say that instead of trying to make very nebulous > and easily breakable extension based checking, maybe this demuxer > should just limit its default usable input formats? >=20 > To my knowledge the officially utilized container formats for HLS are > MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC, > MP3 or AC-3. One could check what hls.js or ExoPlayer support, and > that should be a generally mostly encompassing thing that does not > depend on what extensions are in use. Adding an AVOption to add > additional formats without code changes would then allow for some > outliers to be added by users. there is extended M3U https://en.wikipedia.org/wiki/M3U that allows a wide range of things in it our hls demuxer can read these, if we limit to mpeg-ts/mp4 we would remove support for these. having an AVOption that is needed for some files is bad because then people turn it on and if that makes it insecure ... >=20 > Finally, the `-f` format definition option and whatever logic > underneath it is just splitting the name on comma and then matching. > There probably is a helper function for this in the code base. This > enables just matching against "mp4" or so. While I consider it yeah, you are correct thats ugly, ill fix that michaelni: alternatively I feel like since we've had meta demuxers h= ave these issues having demuxers utilized that just read text from input, m= aybe we should just have some general meta demuxer logic which allows or di= sallows specific formats. allowlist is simpler since even if someone adds a= new one it will not automatically be allowed (thus not enabling possible n= ew "holes"), but on the other hand if we can notice such formats as new ones happen to get added then a bl= ocklist based on a "not allowed in meta demuxers" or "may easily cause info= rmation exfiltration" per-format flag might also be quite possible there are many things that can be done, iam not against this the CVE IIRC explicitly suggested extension checks dont we already have tons of whitelists for things, having a d= emuxer whitelist sounds a lot better then doing it on extension, which is m= eaningless in msot cases - as seen here, ts is just used for anything we have tons of whitelists and i have suggested their use everywhere includ= ing the commit messages They have some problem though and that is they are unflexible if set to a fixed value by hand if you get a unknown generic input what whitelist do you use ? you need to have the demuxer on it that that file needs but you dont know which that is. I dont like hls and i dont like how our hls demuxer is "shared" with more generic EXTM3U code. I think these 2 should be seperate AVInputFormat in the same hls.c Where the true HLS should be more locked down like you describe by default but still teh more generic code benefits from simple checks we can throw at it. Simply blacklisting tty "demuxers" feels like a risky fix though because tty is used by an attacker because its simple not because its the o= nly way to exfiltrate data. If you just run a raw decoder or pcm decoder or even something simple like a RLE decoder you can likely achieve the same its just an extra layer of work Iam not sure and iam not feeling confident on any hls fix. This is all more incremental improvments. Even if you can only run a TS demuxer or MOV demuxer over /etc/passwd, i would not feel safe thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What is money laundering? Its paying someone and not telling the government. --ukSlNzvSBmt9lNW2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ5lPrwAKCRBhHseHBAsP q0yfAKCW+zJEFz8Nh5grPKWtYt42MA6x/gCfaz6xYq/nlF69eeVwMrgdNRBG2tI= =Vpw1 -----END PGP SIGNATURE----- --ukSlNzvSBmt9lNW2-- --===============2164219740758685256== 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". --===============2164219740758685256==--