search

tauri-apps / nsis-tauri-utils

A collection of NSIS plugins written in rust.
Apache License 2.0
16 stars 8 forks source link

Machines with Webroot seem to be detecting nsis_tauri_utils.dll as a virus as of very recently #37

Open ttrushin opened 4 weeks ago

ttrushin commented 4 weeks ago

We have had a Tauri-based application in production with a few hundred users for a while, but today started to get reports of Webroot picking up the nsis_tauri_utils.dll as malware. It is preventing installation of our app.

Here is a VirusTotal scan of the file reported to use by one of our users: https://www.virustotal.com/gui/file/c0f2b928bc4c81cc5ca30a8932a6dc8cd617dd016679c057e23355fe732b2333?nocache=1

I was informed that the issue is fixed via allowlisting in Webroot, but obviously that is not ideal.

Just wanted to add this issue here in case anyone has any thoughts, feedback, or has experienced the same thing.

See screenshot of error during install: Screenshot 2024-07-08 at 16 54 46

ttrushin commented 4 weeks ago

Looks like this is only happening for nsis_tauri_utils v0.4.0

v0.3.0 did not have the issue (just checked with Webroot via their file submission tool): https://snup.webrootcloudav.com/SkyStoreFileUploader/upload.aspx#

v0.4.1 does not appear to have been picked up them yet one way or the other.

Is there any way to force Tauri to use v0.3.0, or to get v0.4.1 out so that the build process starts using it?

FabianLars commented 3 weeks ago

0.4.1 was just a small change so if they check the used win32 this shouldn't make a difference (tauri@git already updated though, will be available in the next release).

0.4 added code that uses CreateProcessW which i assume is the most problematic change there. It fixed a pretty important issue though so idk what we could do here :/ Maybe we could compile 2 versions of the dll and bundle the correct one depending on the installMode. That means the fix wouldn't be included if users manually run the perUser installer as admin but maybe that's a tradeoff worth considering...

ttrushin commented 3 weeks ago

So it sounds like the fix was made for perUser installs but is not really needed when doing perMachine installs because that will have elevated permissions anyway?

Anything we can possibly do to not have whatever is triggering anti-virus works for us, even if it means switching to perMachine installs.

Another question though: if we were to customize Tauri's default NSI file and remove the logic surrounding finding and killing running processes, would the DLL still get auto-included during the bundling process?

FabianLars commented 3 weeks ago

So it sounds like the fix was made for perUser installs but is not really needed when doing perMachine installs because that will have elevated permissions anyway?

No the fix was for "perMachine" or "both" installations, perUser.

Another question though: if we were to customize Tauri's default NSI file and remove the logic surrounding finding and killing running processes, would the DLL still get auto-included during the bundling process?

As far as i can see it'd require cli/bundler changes to not include the dll at all.

FabianLars commented 3 weeks ago

i guess another workaround for now is to downgrade the cli (if possible) to 2.0.0-beta.20 or 1.5.14

ttrushin commented 3 weeks ago

Darn I wish we could downgrade to 1.5.14. Sadly we use signCommand so we get:

Error tauri.conf.json error on tauri > bundle > windows: Additional properties are not allowed ('signCommand' was unexpected)

ttrushin commented 3 weeks ago

We are exclusively perUser. I really wish there was a way to not have to use the new DLL with the fix that technically doesn't impact our installs...

Thanks for the back and forth with me on this, by the way. Would love to figure out a solve, but I understand that you've probably got a lot going on!

ttrushin commented 3 weeks ago

Is there a way to allow Tauri to use a specific DLL, or to customize the link (and hash, which I see the bundler uses) where it pulls the DLL from?

I'm just trying to think of options

FabianLars commented 3 weeks ago

Let's ping @amrbashir and maybe @Legend-Master for their input. (if it's urgent i guess you'll have to fork the repo and use the cli from git for now)

Legend-Master commented 3 weeks ago

Honestly I don't know which part triggered it, if CreateProcess is the problem then how is NSIS's nsExec not a problem which uses ShellExecute under the hood

FabianLars commented 3 weeks ago

I think it's the combination of writing a dll that contains shellexecute to disk at runtime, similar to how many antivir softwares have a problem with rust's build scripts.

ttrushin commented 2 weeks ago

I'm surprised more people aren't chiming in saying they have the same issue. Every time that we install our software on a new user's machine that has Webroot (not common, but certainly not uncommon on corporate machines), installation fails due to this DLL.

We've been allow-listing the DLL by its hash and reattempting installation with success, but it is definitely quite frustrating.

FabianLars commented 2 weeks ago

Yeah, i've not received any complaints in other communication channels either.