NVDA breaks when patching Windows with CWDIllegalInDLLSearch, and its registry value has been set to ffffffff. #907

Closed
nvaccessAuto opened this Issue Sep 16, 2010 · 3 comments

Projects

None yet

1 participant

@nvaccessAuto

Reported by nik62591 on 2010-09-16 04:22
When patching Windows with the CWDIllegalInDLLSearch patch, and setting the registry value to ffffffff, to make all CWD dll searches illegal, even if it is on the local system, NVDA cannot load the NVDA Remote Helper dll. For more information about this patch, see http://support.microsoft.com/kb/2264107

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.

@nvaccessAuto

Comment 1 by nik62591 on 2010-09-16 04:28
If the registry value is set to 2 or less, NVDA does not crash.

@nvaccessAuto

Comment 2 by jteh on 2010-09-16 05:02
It's worth noting that unless you're running from source, the execution directory and cwd are one and the same.

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.
Changes:
Milestone changed from None to None

@nvaccessAuto

Comment 3 by jteh on 2010-09-16 06:28
Fixed in 123bde6.
Changes:
Milestone changed from None to 2010.2
State: closed

@nvaccessAuto nvaccessAuto added the bug label Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2010.2 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment