-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NSIS and nsis-web Installers are being detected as: Suspicious.Win32.Save.a false positives with VirusTotal #6334
Comments
WinShell.dll is the file that flags installers as malicious: Please replace asap |
Odd, that file hasn't been changed since 2019. @develar what's the best way to proceed here? Should these dll's be stored in the repo itself? It seems using a live download link has introduced a vulnerability (not sure how recent either, but seems to persist back through electron-builder v22.10.5: #6347 (comment))
Please advise/act asap since I can only modify this project's repo |
Same issue experienced. My installer with a signed certificate was flagged with NodeJS Version: "14.17.6" Following this for possible resolutions. Thanks! |
Thank you @mmaietta & @develar. I see that there is a new tag When extracted the Any chance this is the solution and that the NSIS binary just needs to be replaced within electron-builder? |
@cliqer great callout!
To:
Note, it's also possible to build using a local download/version of makensis using |
@mmaietta Tried your suggestions and now three threats are being detected with virustotal:
It looks like some malware is using electron with NSIS and antivirus engines have blacklisted the installer for everyone :/ BTW there is one more location that is using the 3.0.4.1 resources and downloads the following:
Maybe the |
@mmaietta Yes, the problem is within the nsis-resources-3.4.1.
Also shouldn't we use the latest NSIS v3.08 while we are on it? |
I agree that would be ideal. I honestly have no idea how nsis installers work or what files we need. For instance, why do we have WinShell? I'm not sure I understand these nsis-resources |
@mmaietta For the time being if we can somehow replace/remove the use of
Tried to figure out how to do that within Do you know, and if so, can you share what needs to be compiled for me to give it a shot? ps. there is a brew of |
@develar can you please advise here?
@cliqer , thanks for all your investigative work here, I really appreciate it. |
Our app has the same issue: https://www.virustotal.com/gui/file/6bafe31fc834c85a785b89aee462ee039a5dbd9b75dbc3b64c4164c80abf3476 In our case SpiderBanner.dll is flagged by SecureAge APEX and the Uninstaller.exe by Sangfor Engine Zero. |
You can omit the SecureAge APEX flag if you purchase a certificate and code sign your app though nothing will change until someone manages to update NSIS and remove these ancient files that throw these warnings. |
Thanks for the info! We've put off buying a EV certificate for some time now... Looks like we have to do so after all. Can I help with compiling NSIS? I have a Win 10 and Linux machine and macOS M1 at my disposal. |
It is not that easy unfortunately (I have tried) and many files need to be amended from @develar which have not responded for 18 days now in this critical issue. Donating since the beginning didn't work either so not much to do actually. About code signing, EV's create more problems than they solve and you can't automate or remote build as you need to put the password manually multiple times per build (at least 4x). |
Off-topic: you can deploy an EV cert to a cloud hosted HSM and use that to sign remotely. You can set it up yourself but it will take some work or you can use ToDesktop CLI (full disclosure: I founded ToDesktop). |
Does anyone know what the resource files are used for? I'm wondering if we can just omit them entirely (they look like they're important.) or if we just need to remove WinShell.dll to remove the vulnerability. I just don't know what might depend on it. The nsis-resources dll files can be found here if you're interested: If we are to move it, then I'm guessing the next best bet might be for me to fork the electron-builder-binaries repo and just maintain all assets there (so that we can remove just WinShell.dll) |
Electron-Builder Version: 22.13.1 Having a similar issue: We use Angular 12.x for the renderer part,
I need to mention that I tried using some third party date pickers instead of the one provided by angular material and I got the same results |
I am also having the same issue. The setup file created by NSIS is being reported as a This seems to be caused only with nsis |
Downgrading to electron-builder |
You can easily test if NSIS is the core issue by using any of these lines in
or
or
|
@mmaietta the issue has already been established for quite some time and an update of NSIS is urgently needed. |
@mmaietta NSIS is the issue. I got it to work without the trojan warning by downgrading the NSIS version to This can be done by adding the following to the build configuration in the project's package.json: "nsis": {
"customNsisBinary": {
"url": "https://github.com/electron-userland/electron-builder-binaries/releases/download",
"checksum": "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==",
"version": "3.0.4.1"
}
},
|
thanks a lot @mmaietta |
Pushed release 22.14.8 w/ [email protected] |
@JCMais I don't think this workaround is actually working. I added some random characters to the url, expecting it to fail the build if a custom NSIS binary is not found, but the build succeeded anyway. I tried adding this config both to package.json and to my electron-builder config file, in the nsis section, however none of them is failing the build. Do you have an idea why this might be happening? |
Use older version of NSIS binaries to avoid malware false positive (see electron-userland/electron-builder#6334 (comment))
Not sure if it will fail the build or just use the default value if the one provided in the package.json is invalid. Changing it like that is working for me. You have to add it inside the "build": {
// ... other options
"nsis": {
"artifactName": "${productName} Setup ${version}.${ext}",
"customNsisBinary": {
"url": "https://github.com/electron-userland/electron-builder-binaries/releases/download",
"checksum": "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==",
"version": "3.0.4.1"
}
}
} |
Good point about build property, I didn't do that in the initial test. I tried now, though, and it still doesn't fail the build. For now I have upgraded to the pre-release version of electron-builder where this is fixed, so this is not relevant for me anymore, but thanks for your help! |
Guys any luck here? Is there any other option apart from downgrading? |
The latest scans as of 2023 do not have detection results. It would probably be best to upgrade NSIS in electron-builder, to use 3.09. Also, it probably isn't worth not upgrading to a newer NSIS package just because one low-quality AV engine has a false positive on any NSIS executable. |
To upgrade makensis, please consider contributing to this repo https://github.com/electron-userland/electron-builder-binaries, then I can open a PR for electron-builder to update it's nsis binary configuration |
These are EV Signed executables where NSIS and nsis-web Installers are being detected as
Suspicious.Win32.Save.a
fromSangfor Engine Zero
with virus total:https://www.virustotal.com/gui/file/caed701727fa4f7805e2ddae9b0a28ec02e07fc6636f9df8da1b748d164583bd?nocache=1
Uploaded and checked each file on its own and none returned as a virus; then created a
nsis-web
and uploaded only the installer that flagged as one immediately:https://www.virustotal.com/gui/file/eb4ebdce32741e4b29f8845fbb54c30022ab7f63bbe90543eccb593ff3cbb414?nocache=1
So it seems something within the installer gets reported as a threat.
Would you please advise of where the problem may be?
Building from an arm64 M1 machine using the latest parallels and Windows 10 Pro Build-21390
The text was updated successfully, but these errors were encountered: