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

[ttrushin]

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:

[ttrushin]

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]

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]

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]

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]

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

[ttrushin]

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]

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]

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]

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]

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]

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]

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]

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

[ajladybug]

FWIW, I am also unable to install due to the same error and Webroot.

[ttrushin]

We have been manually allow-listing the DLL and reattempts are successful, but it is very annoying, and occasionally very difficult when working with enterprise orgs (where getting IT on the line at the time of install can be time consuming).

[amrbashir]

I am replacing nsis_tauri_utils.dll usage with nsis_semvercompare.dll and nsProcess.dll which both shouldn't have any problem with anti viruses, could you give it a try tauri-apps/tauri#11041?

[amrbashir]

I have re-checked [email protected] and it passes all anti viruses https://www.virustotal.com/gui/url/e814a313d4ba77fd51c3d1408c3ba49329a52656a767df50bdcbb867bcf837f6?nocache=1 and passes Webroot as well.

cc @ttrushin