Community
Participate
Working Groups
I'm reporting this against the Java package since this is the only one that's been identified as problematic so far. As we zero in on the problem, we can reclassify the bug. I received an email in the EMO inbox regarding a Neon 2 package (the sender hasn't identified a specific package). There is a post, however, in the forums on the topic [1] that specifically indicates that Symantec is identifying a trojan on the eclipse.exe executable extraced from the Java win32 package. I've checked a few files on a couple of mirrors and the sha512 hashes seem to match what our site is reporting and what is generated directly from the file on our download site. I don't have a Windows box (or Symantec software) handy to test. Can somebody verify? [1] https://www.eclipse.org/forums/index.php/m/1750905/#msg_1750905
Happy New Year Wayne! FWIW, there are free Windows VM images available from Microsoft. They run for a few days and are intended for testing purposes. You can get them here: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ I don't have one set up currently.
We should ask for - a checksum (e.g. sha512sum) of the download ZIP archive - a checksum of the .exe files, especially the eclipse.exe, and its exact size in bytes - a verification of the signature of the executable, i.e. the Windows executable should be signed by the Eclipse Foundation's certificate - the download mirror they were using - the download software (e.g. it could be a malicious download manager) they were using to retrieve the piece of software And after all, it wouldn't be the fist case of a false alarm of a (anti) virus software.
I've gotten a little more information from the reporter. He's had the issue with both the Neon 2 and Oxygen downloads. He says that he's not had the issue with Mars. e.g. http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/oxygen/M4/eclipse-java-oxygen-M4-win32-x86_64.zip I've compared the SHA512 Hashes that he provided for the actual download ZIPs with what's on our download server, so it appears that the mirrors (OSU and Columbia University) are okay. I did a quick comparison between the Platform Runtime Binary produced by the Eclipse Project and the cited Neon and Oxygen package. wbeaton@build:~> unzip -p downloads/eclipse/downloads/drops4/S-4.7M4-201612080830/eclipse-platform-4.7M4-win32-x86_64.zip eclipse/eclipse.exe | sha512sum e9586e726aefee804b7691c4648747f0c382c6f2bc34ea1e287953cb5fa8659abfbc3a329cc5ebde503e6d0ad500e3b5097e6b6db7b24d29876d4f61ae36a2c0 - wbeaton@build:~> unzip -p downloads/technology/epp/downloads/release/oxygen/M4/eclipse-java-oxygen-M4-win32-x86_64.zip eclipse/eclipse.exe | sha512sum 81802002019226787fcfacd1e0745173e9709194e74afdcee4f3c3f6f1ac5d4c4b3df6ebd3210c3815d1aeb4ea0088e53ce57b58a7567e0277ec0d2f4a248f17 - wbeaton@build:~> The hash on the eclipse.exe don't match. I think they should (or have I made an invalid assumption?). I'm not currently able to spin up a Windows instance; as soon as I do, I'll confirm that they're properly signed.
(In reply to Wayne Beaton from comment #3) > The hash on the eclipse.exe don't match. I think they should (or have I made > an invalid assumption?). I did the same comparisons yesterday, but didn't report about the (same) results. AFAIK the only reason for the differences of the Platform and EPP build results is that the Windows executables are signed during the build process, and this build process changes the binary files. An example can be found in the build log of Neon.2 at https://hudson.eclipse.org/packaging/job/neon.epp-tycho-build/505/consoleText [INFO] --- eclipse-winsigner-plugin:1.1.2:sign (sign) @ epp.package.java --- [INFO] Signed /jobs/genie.packaging/neon.epp-tycho-build/workspace/org.eclipse.epp.packages/packages/org.eclipse.epp.package.java.product/target/products/epp.package.java/win32/win32/x86/eclipse/eclipse.exe in 1 seconds. [INFO] Signed /jobs/genie.packaging/neon.epp-tycho-build/workspace/org.eclipse.epp.packages/packages/org.eclipse.epp.package.java.product/target/products/epp.package.java/win32/win32/x86/eclipse/eclipsec.exe in 1 seconds. [INFO] Signed /jobs/genie.packaging/neon.epp-tycho-build/workspace/org.eclipse.epp.packages/packages/org.eclipse.epp.package.java.product/target/products/epp.package.java/win32/win32/x86_64/eclipse/eclipse.exe in 0 seconds. [INFO] Signed /jobs/genie.packaging/neon.epp-tycho-build/workspace/org.eclipse.epp.packages/packages/org.eclipse.epp.package.java.product/target/products/epp.package.java/win32/win32/x86_64/eclipse/eclipsec.exe in 0 seconds. One additional remark: In all cases, the files in the ZIP/tar archives are signed. Someone using the p2 repositories may have different results. The important question is: Do those files on the eclipse.org download servers differ from the files on the user's hard disk?
(In reply to Markus Knauer from comment #4) > AFAIK the only reason for the differences of the Platform and EPP build > results is that the Windows executables are signed during the build process, > and this build process changes the binary files. Noted. I assumed that the Eclipse Project signed the executables. > The important question is: Do those files on the eclipse.org download > servers differ from the files on the user's hard disk? I've asked the user for a hash of the executable. I haven't heard back yet.
I managed to access a Windows 10 box, pulled down the Neon.2 build and ran the up-to-date Avast virus scanner against the executable. It reports nothing. We need to locate a box with an up-to-date version of Symantec. Note that this is a relatively recent addition to Symantec [1], so the other scanners might not have picked up on it yet. [1] https://www.symantec.com/security_response/writeup.jsp?docid=2016-121419-2202-99
Created attachment 270907 [details] screenshot of virus detection This was the screenshot that I got when installing Eclipse directly from the win64 oxygen1 download file.
Created attachment 270945 [details] Screenshot of Virus Detection Symantec Norton
Comment on attachment 270945 [details] Screenshot of Virus Detection Symantec Norton Can confirm. Symantec Norton brought up SONAR.AM.C!g24 while restarting Eclipse after online updating Oxygen to Oxygen 1a.
Is this still reproducible with latest eclipse and symantec versions?
Few months without reply. I assume the issue no longer appears. Please reopen if it still does.
