Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325903

Summary:

[launcher] Windows LoadLibrary search cwd DLL exploit

Product:

[Eclipse Project] Equinox

Reporter:

Andrew Niefer <aniefer>

Component:

Framework

Assignee:

equinox.framework-inbox <equinox.framework-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

jdmiles, mukund, raji, stephen.francisco, tjwatson

Version:

unspecified

Flags:

tjwatson: review+

Target Milestone:

3.4.2+

Hardware:

OS:

Windows All

Whiteboard:

Bug Depends on:

325902

Bug Blocks:

Attachments:

Description	Flags
patch	none

Description Andrew Niefer

2010-09-21 16:19:32 EDT

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

Comment 1 Andrew Niefer

2010-09-22 14:43:17 EDT

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

Comment 2 Andrew Niefer

2010-09-22 17:06:04 EDT

Binaries are recompiled and released.  Tagged as R34x_20100922

Comment 3 Thomas Watson

2010-09-22 17:22:12 EDT

(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').

Comment 4 Andrew Niefer

2010-09-22 17:46:50 EDT

Yes, sorry, the tag contains a 'v', this was just a typo in the comment here.

Comment 5 John Arthorne

2011-04-08 14:45:44 EDT

Removing security advisories group. The fix is available in 3.6.2.