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 3850B41A75 for ; Wed, 15 Dec 2021 20:20:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4159468AD88; Wed, 15 Dec 2021 22:20:33 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8137C68A5DC for ; Wed, 15 Dec 2021 22:20:27 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id C0E1B24017C for ; Wed, 15 Dec 2021 21:20:26 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id zE-V3WhLWL4t for ; Wed, 15 Dec 2021 21:20:25 +0100 (CET) Received: from lain.red.khirnov.net (lain.red.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.red.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 46488240179 for ; Wed, 15 Dec 2021 21:20:25 +0100 (CET) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id 3B73816008E; Wed, 15 Dec 2021 21:20:25 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20211213054336.19783-1-pal@sandflow.com> <163947788654.13029.10298345109744593134@lain.red.khirnov.net> <163950889025.13443.18056291142265665105@lain.red.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 15 Dec 2021 21:20:25 +0100 Message-ID: <163959962513.13029.16441945709966296103@lain.red.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v10 1/2] avformat/imf: Demuxer 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Pierre-Anthony Lemieux (2021-12-15 01:17:26) > > > > Now the question is whether a malicious attacker can craft those two > > files to get access to anything they shouldn't. I suppose at the very > > least the attacker can get information that the user opened the file (by > > adding an asset on an attacker's server) but that will be a danger with > > any playlists allowing network resources and can be controlled with > > io_open(). Can you think of any other possible issues? > > > > Some security considerations: > > - a DDoS can conceivably occur if a malicious CPL+ASSETMAP is widely > distributed. Both an ASSETMAP and a CPL are required since (a) the CPL > does not contain paths/hyperlinks and (b) only those resources > referenced by the CPL are fetched using the ASSETMAP. > - the CPL uses XML, which has its own security considerations. For > example, XML parsing can result in entities being fetched over the > network, but this is disabled by default in libxml AFAIK. This is concerning. From a brief glance at libxml2, it seems that you need to pass XML_PARSE_NONET as the last parameter to xmlReadMemory() to actually disabling network fetching. But it is possible I'm misreading the code, so if you or anyone else understands this better then clarifications are welcome. > - several elements/attributes of the IMF CPL use URIs as unique > identifiers. These URIs could conceivably be dereferenced. > Dereferencing these URIs is however not a requirement and the IMF > demuxer does not do so. > - IMF only uses MXF to wrap essence but supports various kinds of > essence, e.g. Prores and J2K, each with its own security > considerations The demuxer should not be concerned about what the user does with the returned data. Only the behavior of the demuxer itself (and whatever code it calls) is the question here. -- Anton Khirnov _______________________________________________ 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".