[issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
Anthony Wee added the comment: > Thanks Anthony for the report! I included your name as the reporter, though I > don't see it on any of the pages. No problem! Thanks Steve, Eryk, and Victor for jumping on this! -- ___ Python tracker <https://bugs.python.org/issue39401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39401] Unsafe dll loading in getpathp.c on Win7
New submission from Anthony Wee : On Win7, running Python in the terminal will attempt to load the "api-ms-win-core-path-l1-1-0.dll" from various paths outside of the Python directory and the C:\Windows\System32 directories. This behavior can be verified using Process Monitor (see attachment). This is happening due to direct calls to LoadLibraryW() in getpathp.c without any "LOAD_LIBRARY_SEARCH*" flags. In join(): https://github.com/python/cpython/blob/c02b41b1fb115c87693530ea6a480b2e15460424/PC/getpathp.c#L255 and canonicalize(): https://github.com/python/cpython/blob/c02b41b1fb115c87693530ea6a480b2e15460424/PC/getpathp.c#L291 For both cases, the methods they are trying to load from api-ms-win-core-path-l1-1-0.dll (PathCchCanonicalizeEx and PathCchCombineEx) were introduced in Win8. I tested on Win7 and Win10 and they differ in how they load these api-ms-win-* dll's and whether they appear in process monitor. In Win7, a CreateFile event appears in procmon, while in Win10 it seems like the OS is automatically loading the module from kernelbase.dll. Also in Win7 the loading of api-ms-win-core-path-l1-1-0.dll will fail while in Win10 it succeeds. However, in Win7 when it fails it results in the standard dll search strategy, which will eventually search outside of the secure directories such as the directories in the PATH env var: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order Each of the problematic methods in cpython have a pattern of attempting to load the dll, then falling back to an older version of the method. Thus in Win7, the dll fails to load and it falls back to the older version of the method. In Win10, the dll load succeeds and we use the new versions of the methods. I'm working on a fix to pass the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS flag to limit to the dll search path scope. -- files: python unsafe dll loading.png messages: 360348 nosy: anthonywee priority: normal severity: normal status: open title: Unsafe dll loading in getpathp.c on Win7 Added file: https://bugs.python.org/file48855/python unsafe dll loading.png ___ Python tracker <https://bugs.python.org/issue39401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29778] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath
Anthony Wee added the comment: Hm, I'm seeing _Py_CheckPython3() use Py_GetPrefix(), which uses _Py_path_config.prefix? https://github.com/python/cpython/blob/c02b41b1fb115c87693530ea6a480b2e15460424/PC/getpathp.c#L1185 -- ___ Python tracker <https://bugs.python.org/issue29778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29778] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath
Anthony Wee added the comment: Thank you Steve! I'm still seeing python3.dll being loaded from \DLLs\python3.dll. _Py_CheckPython3() uses Py_GetPrefix() as a prefix for \DLLs\python3.dll. It looks like Py_SetPath() sets the _Py_path_config.prefix to "", but I'm not seeing anything else set it to a real value? https://github.com/python/cpython/blob/7b79dc9200a19ecbac667111dffd58e314be02a8/Python/pathconfig.c#L508 -- ___ Python tracker <https://bugs.python.org/issue29778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29778] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath
Change by Anthony Wee : -- pull_requests: +17244 pull_request: https://github.com/python/cpython/pull/17818 ___ Python tracker <https://bugs.python.org/issue29778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29778] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath
Anthony Wee added the comment: It looks like there has been a regression in the fix for this issue. The commit below introduced a NULL check which causes a call to _PyPathConfig_Init() to be skipped if _Py_dll_path == NULL. It seems like the check should be "if (_Py_dll_path != NULL)"? https://github.com/python/cpython/commit/c422167749f92d4170203e996a2c619c818335ea#diff-87aed37b4704d4e1513be6378c9c7fe6R169 -- nosy: +anthonywee ___ Python tracker <https://bugs.python.org/issue29778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
