Community
Participate
Working Groups
An Eclipse-based application can be hijacked during launch by placing a DLL file in the working directory when the application is launched. If the DLL matches the filename of the eclipse companion shared library, it will be invoked instead of the real DLL. This is particularly damaging for applications that associate file types with the executable. For details see: http://securityreason.com/wlb_show/WLB-2010090065
Created attachment 178881 [details] Potential fix v01
We would like to request this fix in 3.4.2 stream as well since Symphony 3.0 where the problem is currently being asked to be fixed is based on that version. Since you were worried about some compatibility risk in fixing it this way would having an ini option to flip back to original behavior be reasonable? Also, just scanning the code I saw multiple calls to checkPath. Though I do think that findLibrary is the only place to worry about, just wanted to ensure that you are confirming our assumption. Thanks for all your help!
I am not an expert in this code. I attached a patch partially because is was the easiest way to describe where the problem is. I would like to wait for Andrew to comment further on whether other calls to checkPath need updating. After thinking more about the compatibility issue, I now think the security risk outweighs any disadvantage of changing the default lookup behaviour. I think we should just change the order, and if requested we could add an option to revert the order back again if that turns out to be useful. Again I would like input from Andrew on this since there may be considerations I'm not aware of.
Some links: Original Advisory URL: http://core.yehg.net/lab/pr0js/advisories/dll_hijacking/[ibm_lotus_symphony]_3-beta-4_insecure_dll_hijacking Workaround Solution: http://support.microsoft.com/kb/2264107 Workaround Solution: https://www.microsoft.com/technet/security/advisory/2269637.mspx#EGF Developer Solution: http://msdn.microsoft.com/en-us/library/ff919712%28v=VS.85%29.aspx Unofficial DLL Hijacking List: http://www.corelan.be:8800/index.php/2010/08/25/dll-hijacking-kb-2269637-the-unofficial-list/ Testing for DLL Hijacking: http://core.yehg.net/lab/pr0js/view.php/when_testing_for_dll_hijacking.txt
This affects products using --launcher.library with a relative path. In the particular case of Symphony, they are using "--launcher.library ./eclipse_1114.dll". In a more standard eclipse product, the spoofed dll would just need to be placed in an appropriate plugins/org.eclipse.equinox.launcher.* folder This affects all platforms. There exists a similar vulnerability around the -vm argument, if the eclipse.ini gives a -vm argument with a relative path ending in .dll/.so (ie "-vm jre/bin/client/jvm.dll"), then the vm dll can be spoofed as well.
We do not consider placing the spoof dll in the plugin a security problem. We expect the plugins to be in a secured directory. The case we are worried about is where the spoof eclipse dll is placed in the launch/cwd directory. In that case the spoof dll is loaded. It does not have to be in a secured location.
(In reply to comment #5) > In a more standard eclipse product, the spoofed dll would > just need to be placed in an appropriate plugins/org.eclipse.equinox.launcher.* > folder This is not the eclipse plugins folder, but a plugins folder in the current working directory. A normal 3.6 eclipse could be spoofed with C:\WorkingDir\someAssociatedFile.ext C:\WorkingDir\plugins\org.eclipse.equinox.launcher.win32.win32.x86_1.1.0_v20100503\eclipse_1307.dll it can also be spoofed via java code: C:\WorkingDir\plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar
Created attachment 179323 [details] Patch v2 I believe that changing the calls to checkPath is the best way to go here. This patch modifies the search for all of the shared library, the vm and the launcher.jar to check the program directory before checking the current working directory. A normal eclipse install is only vulnerable to the shared library and launcher.jar attacks. The vm affects products specifying a relative -vm path in the eclipse.ini
Andrew, the patch looks fine. I do wonder if we should just ignore the reverseOrder flag in checkPath and always search the programDir before the workingDir. There is a checkPathList in eclipseUtil.c that has a reverseOrder flag. I'm not sure what this is used for or if there is a similar concern there. It ends up calling checkPath and could result in the workingDir being searched before programDir. All other calls to checkPath seem to pass 1 for reverseOrder flag.
In the 3.4.2 branch, all the calls are now passing 1, however, in 3.6 there is one call passing 0 to resolve the arguments for --launcher.openFile against the working dir first. Arguably, in this case we probably don't want to check against the program directory, but it was easiest to just reuse the code.
Thanks Andrew, perhaps we should restructure that part of the code in 3.7 to make it more clear. I approve of the current patch for 3.6.2 and earlier.
*** Bug 323511 has been marked as a duplicate of this bug. ***
I have released this patch and recompiled for HEAD but not yet in 3.6.x
This has been released to the 3.6.2 branch, compiled and tagged.
Removing security advisories group. The fix is available in 3.6.2, and the exploit is already public anyway (see comment #0).
