Community
Participate
Working Groups
In my case this is causing problems for my Application Whitelisting solution. Every time there is a New dll file we need to update Our ruleset.
I've gotten a report now of a customer having their SWT DLLs getting infected by malware. In the customer's case, the infected SWT DLLs were the ones extracted/cached by the OSGI framework in the workspace directory. You know, one of those fun locations like configuration\org.eclipse.osgi\631\0\.cp\*.dll where the files are in the user home directory, and are thus (over)writable by all user processes, including malware? Unlike the known-good files kept in the installation directory, which require admin permissions to overwrite? If eclipse/osgi is going to be copying SWT DLLs to the user directory before loading them, then these SWT DLLs should REALLY be signed in all releases! (I'm saying this under the assumption that malware would violate the signatures when overwriting, thus keeping them from being subsequently loaded, but this is admittedly not my area of expertise.) If my understanding of the underlying security problem is correct, then I'd propose that this is not a P3 Enhancement, but is instead a P1 critical security issue.
(In reply to Rob Sigel from comment #1) > If eclipse/osgi is going to be copying SWT DLLs to the user directory before > loading them, then these SWT DLLs should REALLY be signed in all releases! > (I'm saying this under the assumption that malware would violate the > signatures when overwriting, thus keeping them from being subsequently > loaded, but this is admittedly not my area of expertise.) Bad signature doesn't prevent DLL loading.
(In reply to Nikita Nemkin from comment #2) > (In reply to Rob Sigel from comment #1) > > If eclipse/osgi is going to be copying SWT DLLs to the user directory before > > loading them, then these SWT DLLs should REALLY be signed in all releases! > > (I'm saying this under the assumption that malware would violate the > > signatures when overwriting, thus keeping them from being subsequently > > loaded, but this is admittedly not my area of expertise.) > s. > Bad signature doesn't prevent DLL loading. It does if you run applocker or any other dll whitelisting solution. Which is starting to become very common. Also executables should be signed, period.
Thanks for the quick response! Even if a bad signature doesn't prohibit DLL loading (at sites where whitelists aren't used), a bad signature DOES help *immediately* show that the infected DLL on a user system is NOT the same DLL that Eclipse shipped. It helps avoid poor publicity and misplaced blame. My current customer is trying to blame us (and Eclipse) for the problem, while I'm trying to convince them (by pointing at the uninfected DLL in the signed jar, also visible on their machine) that the infection happened on their own machine, and was not present in the application as-shipped. The customer is also pointing out that extracting unsigned DLLs into user-writable space is poor/insecure design, and I can't disagree with them. But since this is a design decision in the underlying OSGI/Eclipse frameworks, I'm not aware of anything I can do about it either... As a workaround for the security aspect, is there any ini file, env var, command-line option, or other configuration change I can make to keep the presently-unsigned SWT DLLs from ever being written to the configuration directory (or any other user-process-writable directory, including temp dirs) at runtime, so that the DLLs are never able to be infected by malware?
(In reply to Rob Sigel from comment #4) > As a workaround for the security aspect, is there any ini file, env var, > command-line option, or other configuration change I can make to keep the > presently-unsigned SWT DLLs from ever being written to the configuration > directory (or any other user-process-writable directory, including temp > dirs) at runtime, so that the DLLs are never able to be infected by malware? The SWT fragments that contain the DLLs could be shipped as directory bundles such that they are extracted to a directory in the plugins/ folder which I would assume is OK since that is the installation of eclipse itself. We are limited by what the JVM can do to load libraries. It requires there to be a file on disk with the native library.
I noticed that the DDL's in the latest nightly build are signed, both in the jar and the check in versions. (v4928r12e) Is somebody actively changing the build configuration, or is this a side effect of earlier changes? I can't find a commit related to those changes.
(In reply to Rolf Theunissen from comment #6) > I noticed that the DDL's in the latest nightly build are signed, both in the > jar and the check in versions. (v4928r12e) > > Is somebody actively changing the build configuration, or is this a side > effect of earlier changes? I can't find a commit related to those changes. Something along bug 548431 commits?
(In reply to Andrey Loskutov from comment #7) > (In reply to Rolf Theunissen from comment #6) > > I noticed that the DDL's in the latest nightly build are signed, both in the > > jar and the check in versions. (v4928r12e) > > > > Is somebody actively changing the build configuration, or is this a side > > effect of earlier changes? I can't find a commit related to those changes. > > Something along bug 548431 commits? Thats correct. I made changes to SWT build scripts to sign SWT build fragments. Also the Launcher fragments are also signed now
(In reply to Sravan Kumar Lakkimsetti from comment #8) > > Something along bug 548431 commits? > > Thats correct. I made changes to SWT build scripts to sign SWT build > fragments. Also the Launcher fragments are also signed now So can we close this one, or make a duplicate of bug 548431?
The SWT build artifacts are signed now. resolving
