Community
Participate
Working Groups
SWT loads its Windows DLLs (swt-gdip-win32-[version].dll and swt-win32-[version].dll) in an insecure manner, which may result in cross-user privilege escalation and arbitrary code execution within a user's local session. Specifically, while the DLLs are expected to be in a specific location under the user's profile (which is already weird) - specifically, %USERPROFILE%\.swt\lib\win32\x86 for 32-bit - the way they are loaded means that many other locations are checked for those DLLs first, including some that may contain malicious files (most notably, the working directory of the process, which might be a public or untrusted location). If SWT loads the wrong DLLs, it can lead to arbitrary code execution within the Java process. Exploit scenario: * An attacker with non-Administrator access to a shared computer crafts a DLL that executes malicious code in its DllMain function (which executes whenever the DLL is loaded). * The attacker names this DLL "swt-win32-[XXXX].dll" (where XXXX is a current version number) and places it in a shared directory. * The attacker convinces another user to run a SWT-using application with that directory as its working directory (this may not require any "convincing" at all; some applications install shortcuts that automatically set the working directory to a shared location). * The attacker's code runs in the other user's JVM process, giving the attacker access to the victim's Windows account. Repro steps: 1. Take the SWT DLLs and place them in a location that is not their usual directory but where an attacker may have access, such as a public directory (writable by all users on the local machine) or a Downloads directory (where a to where a user may have downloaded a malicious file). 2. Put a Java program (a .JAR, or .EXE that points the JVM at a .JAR) that uses SWT in the same location where the SWT DLLs were planted. 3. Run the Java program. 4. Use a tool that can show loaded modules (including DLLs), such as "Resource Monitor" (built into Windows) or "Process Explorer" (part of Microsoft's free Sysinternals suite) to see what DLLs the java[w].exe process has loaded. Expected: The JVM process should have loaded the DLLs from a known location, such as the default location under the user profile as mentioned above or some other secure location. Observed: The JVM process loads the DLLs from the working directory. Remediation: Use a fully-specified path to the DLLs when loading them. Do not simply provide the DLL name. For more information on this security issue and its remediations, see https://msdn.microsoft.com/en-us/library/windows/desktop/ff919712(v=vs.85).aspx
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.
