[issue27410] DLL hijacking vulnerability in Python 3.5.2 installer

[Eryk Sun]

Eryk Sun added the comment:

> installer attempts to load DLLs from the current directory

It's actually the application directory that's the culprit, not the current directory. All supported versions of Windows default to SafeDllSearchMode, which moves the current directory after system directories. However, the loader (and also the CreateProcess family) default to searching the application directory before system directories. Known DLLs [1] aren't vulnerable, and AFAIK neither are DLLs loaded from system API Sets, which is typically how ucrtbase.dll gets loaded. 

The problem could be worked around by calling SetDefaultDllDirectories (requires KB2533623 prior to Windows 8) to disable searching the application directory. For static imports, I suppose one could delay loading them until after SetDefaultDllDirectories is called. There should really be a way to control this behavior in the application manifest. Giving the application directory priority when looking for DLLs and EXEs is fine for securely installed applications, but not for installers and the like.

[1] HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs

----------
components: +Windows
nosy: +eryksun, paul.moore, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27410>
_______________________________________