Conversation
Collaborator
|
Bump PyWin32 to fix vulnerability issue |
bebound
approved these changes
Dec 27, 2022
Member
Author
Why/How
|
jsntcy
approved these changes
Jan 3, 2023
yonzhan
approved these changes
Jan 3, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change
Bump PyWin32 (to >= 303) so that Azure CLI no longer loads
pywintypes310.dllorpythoncom310.dllfrom the current working directory (CWD), but always fromC:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\pywin32_system32\.Context
LoadLibraryandLoadLibraryExWin32 APIAccording to https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications, even if
SafeDllSearchModeis enabled and it places the user's current directory later in the search order, the current directory is still searched byLoadLibraryandLoadLibraryEx.LoadLibraryExsupports additional flags such asLOAD_LIBRARY_SEARCH_DEFAULT_DIRSandLOAD_LIBRARY_SEARCH_DLL_LOAD_DIR. When these flags are specified, directories in the standard search path are not searched, so the current directory is no longer searched.Python 3.8's DLL loading mechanism change
https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-python-api
bpo-36085 is migrated to python/cpython#80266.
In summary, when loading DLLs:
LoadLibraryExWis called withLOAD_WITH_ALTERED_SEARCH_PATH.LoadLibraryExWis called withLOAD_LIBRARY_SEARCH_DEFAULT_DIRSandLOAD_LIBRARY_SEARCH_DLL_LOAD_DIR, more securely (bpo-36085: Enable better DLL resolution on Windows python/cpython#12302)PyWin32's DLL loading mechanism change
Since version 303, PyWin32's
_win32sysloaderswitched from callingLoadLibrarytoLoadLibraryExwith the sameLoadLibraryExflags as Python itself mhammond/pywin32#1794.Therefore, PyWin32's change causes the current directory no longer to be searched, but its change log doesn't mention this:
https://github.com/mhammond/pywin32/blob/d73b0200eba81fa551b90d15cf5da097f4197f8f/CHANGES.txt#L92-L93
Testing guide
The test can be done with system Python, without Azure CLI's embedded Python.
With PyWin32 302, DLL can be loaded from the current directory:
With PyWin32 305, DLL cannot be loaded from the current directory and results in an
ImportError: