Steve Dower added the comment: It's not even that the risk is low, it's that we can't actually fix it. There are zero explicit DLL loads in the installer (either the part we own or the third-party core) that are insecure, and the four DLLs referenced by the third-party core executable that are not listed as KnownDLLs are Windows system DLLs that could be used by any downloaded executable - in particular installers, which are most likely to show up in a downloads folder.
If a user is not knowledgeable enough to avoid "accidentally" downloading a file from a website, is not perceptive enough to notice an unexpected download, and/or is not paranoid enough to run installers from their own directory, they are going to be affected by this design decision in the operating system through some other installer. We are already more secure than most, since we don't elevate by default. The 7-zip installer (which just happened to be first in my downloads folder) is more vulnerable to this, in that it will load version.dll from the downloads folder and execute code as Administrator. We will only run it as the current user, which is certainly a vector to start executing code, but it's not one that we can possibly close off. If someone wants to report this flaw to the Microsoft security team, they can consider changing Windows to add these DLLs to the KnownDLLs list and ensure that the system's version is always loaded. The most we can do is publish an article for paranoid people to protect themselves (which I am not volunteering to write). ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27410> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
