You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: