Re: [FFmpeg-devel] [PATCH v2] libavformat/vapoursynth: Update to API version 4, load library at runtime

[Stefan Oltmanns via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

Am 22.07.24 um 14:13 schrieb Ramiro Polla:
> On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes <h.leppkes@gmail.com> wrote:
>> On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel
>> <ffmpeg-devel@ffmpeg.org> wrote:
>>>
>>> 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
>>>
>>
>> Relaxing security considerations to avoid a 10 line function seems not
>> worth it to me. So go with actually finding the correct path.
>
> I would prefer changing w32dlfcn.h to allow loading DLLs from PATH.
> Limiting to only the directory of the executable and system32 seems
> too excessive to me. Removing the current working directory is more
> understandable, but it's perfectly fine to expect PATH to be searched.
>
> Also, we don't have such restrictions on other platforms.
> (DY)LD_LIBRARY_PATH still work as expected.
>

I had a look at the documentation from LoadLibrary: That does not seem
to be an option, you cannot explicitly allow PATH. If you want to allow
PATH, you need the option for default search directories and that will
also include the current working directory.

You can use custom search paths (that's what ffmpeg does for older
Windows where these flags don't exist), but those have to be explicit,
so no help here.

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