Dylibs built on 1.78.0 <->1.87.0 gets flagged as trojans

[Godnoken]

Code

Building dylibs from 1.78.0 stable and onwards creates .dlls that are flagged as trojans.
Tested on two different Windows 10 PCs with fresh installs.

1.78.0 cargo init dylib https://www.virustotal.com/gui/file/65e2ea31d0bc03ef70e3c342a7cddcabd22be2db5fd84dfbb4db18dd01e3c083/detection

1.77.0 cargo init dylib https://www.virustotal.com/gui/file/5b4fb7bfa7a13acc42f640bb4d6382cc820b499d010a64727326f006b23a4e46/detection

Version it worked on

It most recently worked on: 1.77.0

Version with regression

Anything past 1.77.0

---

I've looked here in the issues, forums, discord, google.. nada. I wonder how this hasn't been mentioned before?

This is quite annoying even though it is a false positive. My users are messaging me wondering why there is a trojan coming with the installation.

[saethlin]

Similar issues have been reported in the past:
https://github.com/rust-lang/rust/issues?q=is%3Aissue%20virustotal%20

And I have seen discussion in the community of false positive virus detection on Rust programs. Perhaps this is the first report I've seen of this specific issue, but the pattern is well known.

It is extremely unlikely that we will make any change to the compiler or standard library to prevent these false positives. These usually happen because virus detection tools get trained on some piece of malware written in Rust and then the people who maintain those tools don't realize that the pattern they've extracted is Rust in general, not the specific malware. Even if we change the relevant compiler output, these tools will just get re-trained to again claim Rust programs are malware. The fix needs to be in those tools.

[Godnoken]

Similar issues have been reported in the past:
https://github.com/rust-lang/rust/issues?q=is%3Aissue%20virustotal%20

Still can't see any virus false positives in there, but I'm sure you're right.

And I have seen discussion in the community of false positive virus detection on Rust programs. Perhaps this is the first report I've seen of this specific issue, but the pattern is well known.

Yup, saw a few older posts about similar issues, I was just surprised that I couldn't find anything on this specific flag.

It is extremely unlikely that we will make any change to the compiler or standard library to prevent these false positives. These usually happen because virus detection tools get trained on some piece of malware written in Rust and then the people who maintain those tools don't realize that the pattern they've extracted is Rust in general, not the specific malware. Even if we change the relevant compiler output, these tools will just get re-trained to again claim Rust programs are malware. The fix needs to be in those tools.

Alright, thank you very much for the insight on this. Makes it easier to explain for end-users.

[saethlin]

Still can't see any virus false positives in there

#90647 and #93187.

[workingjubilee]

@Godnoken All the cases flag it as a "Gen" variant. As in "General" or "Generic". The program's behavior was examined and found to do something that looks like a virus, it was not found to be malware beyond a doubt.

For example, reading files, then writing files, especially "outside the program's initial directory", is arguably what anything that steals secrets or replicates itself would be doing.

Or, for instance, trying to call system software that most programs don't need, like e.g. the tools for examining and unwinding the stack...

...You know, so a backtrace can be generated?

[workingjubilee]

Almost all the vendors in question have somewhere on their site you can submit a false positive report. Sometimes it's only an email, usually it's a little webform. Sometimes they even have an API you can work with to automate correct detection (this is, unfortunately, rarely the case with the majority of those that have many false positives). I recommend submitting all instances of your dylib that get a false positive detection on VirusTotal to those vendors.

[workingjubilee]

As for your clientele, I recommend pointing out that many antivirus vendors on VirusTotal, including ones that extensively work with Rust (like, say, Microsoft), do not flag these binaries. If you feel confident in their average technical acumen, you may wish to try to delve into the technical explanation.

My understanding of most such software vendors is that they take into account "the user said there wasn't anything bad about this file" if enough such "that was a false positive" reports come in, which may combine with your direct report as the developer to get a swifter response.

[Godnoken]

@Godnoken All the cases flag it as a "Gen" variant. As in "General" or "Generic". The program's behavior was examined and found to do something that looks like a virus, it was not found to be malware beyond a doubt.

For example, reading files, then writing files, especially "outside the program's initial directory", is arguably what anything that steals secrets or replicates itself would be doing.

Or, for instance, trying to call system software that most programs don't need, like e.g. the tools for examining and unwinding the stack...

...You know, so a backtrace can be generated?

Thank you for elaborating on this, makes it a whole lot easier to understand. My knowledge of viruses and antiviruses has been extremely superficial up till this point.

Almost all the vendors in question have somewhere on their site you can submit a false positive report. Sometimes it's only an email, usually it's a little webform. Sometimes they even have an API you can work with to automate correct detection (this is, unfortunately, rarely the case with the majority of those that have many false positives). I recommend submitting all instances of your dylib that get a false positive detection on VirusTotal to those vendors.

As for your clientele, I recommend pointing out that many antivirus vendors on VirusTotal, including ones that extensively work with Rust (like, say, Microsoft), do not flag these binaries. If you feel confident in their average technical acumen, you may wish to try to delve into the technical explanation.

My understanding of most such software vendors is that they take into account "the user said there wasn't anything bad about this file" if enough such "that was a false positive" reports come in, which may combine with your direct report as the developer to get a swifter response.

Thank you very much, I will look into it, hopefully they'll be receptive and be able to get rid of these flags. And I'll take your advice on explaining this to users! :) Cheers.

[Godnoken]

Still can't see any virus false positives in there

#90647 and #93187.

I just clicked on the same link but from my PC this time, now I see the same issues. Turns out that the link either doesn't work on the mobile version or it shows completely different results.