This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients anandbhat, chrullrich, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2016-06-29.12:19:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1467202768.33.0.36137603097.issue27410@psf.upfronthosting.co.za>
In-reply-to
Content
> 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
History
Date User Action Args
2016-06-29 12:19:28eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, chrullrich, anandbhat
2016-06-29 12:19:28eryksunsetmessageid: <1467202768.33.0.36137603097.issue27410@psf.upfronthosting.co.za>
2016-06-29 12:19:28eryksunlinkissue27410 messages
2016-06-29 12:19:27eryksuncreate