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.
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.