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 981F744DD0 for ; Sun, 21 Jul 2024 22:08:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9247368D681; Mon, 22 Jul 2024 01:08:28 +0300 (EEST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DC0ED68D4C1 for ; Mon, 22 Jul 2024 01:08:21 +0300 (EEST) X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.11.12] ([85.8.102.145]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MjjCL-1s3Eju0mnD-00acUd for ; Mon, 22 Jul 2024 00:08:21 +0200 Message-ID: <39e062c8-652f-4df9-b267-4db601fb9b46@gmx.net> Date: Mon, 22 Jul 2024 00:08:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <8c6c11a6-bc55-41a0-9f98-262c60f63ec8@gmx.net> <09b1f1e5-4e05-4c99-9451-28be33bfd9ba@gmail.com> <52bcfca2-2666-4c95-927b-d22714568714@gmx.net> <5fb71a99-92e3-45b3-9a36-f9fe912b24f5@gmx.net> Content-Language: de-DE, en-US In-Reply-To: X-Provags-ID: V03:K1:6wUxjo+SfiPhbe9Fvw5uNFq9eVI3co7g9B7RmaxtdnTAcjDfNt5 f2O+BOalNa+l3S2Fe1QS8K1VUu3JqxTrGvI8mGsfVP3AqjXOzKSuwzOs6u+xezD6b7PkWOb gugBM0KbST1AwaHSfArqQJkF/91PIyRGewcLYgertTj66TkezdBIrwUwTBznBNKRE9a+Iwx CcjVlttFRQ3BzSKMX9ynQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:gH9WJhjPC3k=;B3rJLCtZ9bYbW1emgjtltm2OvvF V4jj2zELYKBpPW26bCR5U1Ilpj2E1sB26qk9H2lN2nDhCbLNEqbKif8qkHV7nQp+uZZB4l6NI isRbK8CWyStoZ//lttDpyxW2HBArQU3s7/uSLCd5P3DaV3CkVH2oz1fJ1Jh40F1uZ8cGN1RNt Xr3I1Xw+W9jgZzBSqVpgv+hWnlZcASR2kk8pILGH8ak1D+NH8v8Uc0K3+porb8e7uOEg3yRpF 8TwQ4Wn3GKIO9inKpxsFEfDuA4DvVnNyazv6ILe5oz1ysIyE3/DtQI7yHoDi6wTNwZIcvfSe4 cd6WJQcHdRLpkbW341u8D205xBw5K0CzLJC/Eya6o0F9U4DEvHFFAE90Wikcf4hNaZWqqZJco QnsGb+jz7cmulVROhs7hwSUm0kL0ZLzvC/A+J6BmmHH/xAH5P1yy+1U0kzWv4nxt6RzVPDjCG fIp/FIKCUZENOrIvPJUWkYxFT8q/U4IX9d+GIXcPDIXP8ApmQADlJQHgLoph+RaM86MOlT3Vh LpwNrXJP2AwkYXy1zGYcYJnzVg9KpwnG2XU2M+4QXJ/BMd2FSMtxiSlu383BMzHgXcdlGX+O9 pi3iG/eTeKEyMQQ6Q9eRezCtMXzWsQ8EHCr6cjvb6yaPHlUWm1ZP+kod6Aa4mo5FfmwDB4lFP qkwyUhHDyr1oBwyhyv98Qj+VU84Qh6HaYHDwgBwJbaO+MgY/MWBZPslSKmK41MU8uGFw3R//T UNKZuEUuhz7qAwpoTi5oLliKJOoHXfyGz9Ox8EqwMcXrb9YnzygUPOWxwaxOJm+pvRac5I8+Q 85gat9CMJtGzvdtYyTzTlDqA== Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/vapoursynth: Update to API version 4, load library at runtime 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: , From: Stefan Oltmanns via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Stefan Oltmanns Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Am 18.07.24 um 17:23 schrieb epirat07@gmail.com: > >>> >>> Well, the DLL directory is added to PATH by the VapourSynth installer, >>> but for safety reasons ffmpeg explictly tells the LoadLibrary function >>> to only search the application directory and system32, quote from >>> w32dlfcn.h: >>> >>>> /** >>>> * Safe function used to open dynamic libs. This attempts to improve program security >>>> * by removing the current directory from the dll search path. Only dll's found in the >>>> * executable or system directory are allowed to be loaded. >>>> * @param name The dynamic lib name. >>>> * @return A handle to the opened lib. >>>> */ >>> So ffmpeg prevents that solution on purpose. Or should that behavior be >>> changed in the w32dlfcn.h? >> >> Oh, bummer. I would expect that overriding the PATH environment >> variable would work kind of like how LD_LIBRARY_PATH works on Linux. I >> don't know why that was changed. I don't really follow what goes on in >> Windowsland anymore. Does anyone else care to comment on this? Martin, >> maybe? > > IIRC this is done to prevent DLL injection attacks > > https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security > So what's your proposal how to continue? I see different options with pros&cons: 1. Read the DLL path from registry, function for that could be located outside the VapourSynth module. Pro: Safest method to protect from DLL-injection Con: A lot of custom code/functionality for Windows 2. Change w32dlfcn.h to allow loading DLLs from PATH Pro: Minimal code-change, highest similarity between different OSes Con: Open for DLL-injection attacks the current implementations wants to prevent. 3. Allow loading DLLs from PATH with a special flag when calling dlopen. dlopen has a parameter for flags, we could define a WIN_ALLOW_LOAD_DLL_FROM_PATH for Windows that will enable load from PATH Pro: Reduced risk for DLL-injection attack, high similarity between different OSes Con: Flag needs to be defined 0 for other OSes, Posix flags need to be defined 0 for Windows (currently not needed, as the flags are thrown away by the pre-processor) Best regards Stefan _______________________________________________ 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".