Summary: | Insecure DLL loading (swt-[gdip-]win32*.dll) | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Christopher Hacking <christopher.hacking> |
Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | lshanmug, nikita, niraj.modi, sravankumarl, wayne.beaton |
Version: | 4.5.2 | Keywords: | security |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 10 | ||
See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=548443 | ||
Whiteboard: |
Description
Christopher Hacking
2018-02-28 16:37:35 EST
Hello, any updates on this issue? Is this component still maintained? This is a potentially serious security issue, turning execution of a trusted program into execution of arbitrary untrusted code. If more information is required, please specify. If this issue will not be resolved by the maintainers, we need to know that. Any progress here? The handbook has some help regarding how we handle vulnerability reports. https://www.eclipse.org/projects/handbook/#vulnerability SWT locates its libraries in the following order: 1) Check the path in swt.library.path; 2) Ask JVM (which searches in java.library.path); 3) Check ~/.swt; 4) If nothing is found, unpack into ~/.swt and use that. Note that steps 1, 3 and 4 use absolute paths to load DLLs and aren't vulnerable to injection. Step 2 uses java.library.path, the standard JNI search path, which does contain the current directory by default (on Windows). It also contains the whole PATH and some other junk. SWT can't ignore java.library.path, it's the platform convention and is expected to work. So it's up to the application/launcher to set java.library.path to a secure value. |