Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #325902 +++ 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
Created attachment 179399 [details] patch Here is the patch I'm currently working with. I have confirmed it does prevent finding dlls in the current working directory, I have run under both ansi and unicode versions. the patch for >=3.6 will differ slightly as we are unicode only starting in 3.6. The launcher is currently being compiled with _WIN32_WINNT=0x0400, rather than changing this to 0x0502 and using the GetVersionEx to see if the SetDllDirectory method is available, I've instead loaded the Kernel32.dll and looked for the symbol directly. This is a pattern we've used before on various platforms (GetConsoleWindow is an example on windows). Note this code is in the shared library, not first thing in the exe. This does allow for updating via p2. We have no code looking for shared libraries on the search path before here, the "Kernel32.dll" loading is safe because it is found in the system directories which are checked before the working directory, (as well, it is likely that the kernel32 image is already in memory because we do link with that library).
Binaries are recompiled and released. Tagged as R34x_20100922
(In reply to comment #2) > Binaries are recompiled and released. Tagged as R34x_20100922 The map file indicates R34x_v20100922 tag was used (with a 'v').
Yes, sorry, the tag contains a 'v', this was just a typo in the comment here.
Removing security advisories group. The fix is available in 3.6.2.
