Description Andrew Niefer 2010-09-21 16:18:25 EDT

On windows, the default search when loading native libraries with LoadLibrary without an absolute path searches the current working directory before the windows search path. [1]

Therefore, native code trying to load a shared library that it expects to find on the windows search path is vulnerable to a malicious dll being placed in the current working directory in a manner similar to bug 325294

The proposed fix is to call SetDllDirectory[2] to remove the cwd from the search.

For > 3.6.x we may want to also add the cwd to the end of the PATH env variable to preserve finding libraries there but still closing the vulnerability.  We must also ensure that this change affects the child vm process when the vm is not in-process.

[1] http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx
[2] http://msdn.microsoft.com/en-us/library/ms686203%28v=VS.85%29.aspx