Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
NVDA breaks when patching Windows with CWDIllegalInDLLSearch, and its registry value has been set to ffffffff. #907
Reported by nik62591 on 2010-09-16 04:22
If the registry value is set to 2 or less, 2 meaning that running a dll from the CWD is always illegal when running on a remote computer, but not locally. The issue is most problematic because one can open a file on a remote server, and the application will change into that remote directory and use the remote dll, allowing an attacker to run code on the target's system. I set the registry value to ffffffff, so that dll's can never be called by searching the cwd, even if the dll is local. My reasoning for this is that an attacker could send a zip file with media on it, and the target would extract the zip, open the media, the program would change to the directory of the media and the dll would be called. I'm not sure which archival formats contain attributes, but if they do, the hidden attribute could be set on the dll, worsening the issue.
This issue is relatively miner; one must manually patch his or her system; it is not pushed via Windows update, as far as I know. Also, the user must manually set the registry value to ffffffff, and most wouldn't do this since that policy is a bit restrictive. But I am reporting this because if this change were to ever have the chance to be the default, or if one simply wishes to have this value set, applications must not break. It is possible to manually set this option for specific applications, but still, NVDA shouldn't be calling dll's as searched from the cwd, it should immediately be called from the execution directory, although if this is a Python issue, I'm not sure how much can be done from within NVDA.
Comment 2 by jteh on 2010-09-16 05:02
I notice that there's no complaint when we load nvdaHelperLocal.dll (we load this before remote), which is also in lib, so this is obviously fine. This makes me think the problem is due to our use of the LOAD_WITH_ALTERED_SEARCH_PATH flag to !LoadLibraryEx, rather than loading a dll from the lib directory. If I'm right, this makes the LOAD_WITH_ALTERED_SEARCH_PATH flag totally useless. Unfortunately, I'm not sure how we can make nvdaHelperRemote.dll load minHook, etc. from the lib directory without using !LoadLibrary, which will require quite a bit of code refactor.
Anyway, we should first try passing an absolute path to !LoadLibraryEx, which is trivial. If this doesn't work, we'll need to further investigate the above.