3 ms·

According to the linked issue, it's not just Windows Defender; 21% of scanners reported by VirusTotal also flag D. What could cause so many independent virus ch

According to the linked issue, it's not just Windows Defender; 21% of scanners reported by VirusTotal also flag D. What could cause so many independent virus checkers to throw a false positive like this?

viraptor 8y ago
Can't find the details now, but there were cases before of AVs using VirusTotal for getting their answers if they lacked any info / signatures for a binary. Could be what happened here, so they're not really independent. Edit: this describes the issue - https://mma.prnewswire.com/media/727967/VirusTotal_and_the_Comodo_Zeroday_Challenge_Black_Hat_2018.pdf https://mma.prnewswire.com/media/727967/VirusTotal_and_the_C...
cookiecaper 8y ago
AVs throw these all the time, for all kinds of applications and tools. They're triggered by patterns and signatures in the executable that "may indicate malicious behavior", etc., heuristically. It's in the AV vendor's interest to be overzealous and have lots of false positives rather than to have a single accidental false negative.
windwake12 8y ago
It's pretty common for programs compiled by "uncommon" compilers, and since the D compiler is selfhosted, it would fall into that category. AV software isn't magic, they probably just look for stack/calling/allocation patterns that don't look "right" meaning none of the major compilers generate such code, and it "might" be bad somehow. I've a few flags from npm with Kaspersky, because there's so many packages that include some little binary, and since this is npm, it's often "unusual", like go.
- ynik 8y ago
  The AV might not be even looking at patterns in the executable code. We've had an issue where we accidentally ran the msys strip tool over binaries compiled with the MSVC compiler. A quarter of the scanners on virustotal went crazy and "detected" our program. The same unstripped program was fine with them. And by "the same", I literally mean the same: virustotal showed that all sections in the "malicious" stripped executable had identical hashes to those in the clean unstripped executable. The only difference was some header bits that were irrelevant to the runtime behavior (I think it was the "linker version" field, and maybe some others).
drdrey 8y ago
They may not be as independent as you would think. For instance. There could be straight-up signature sharing or outsourcing between vendors, and there is definitely an incentive to flag something if your competitors also flag it.
- vatueil 8y ago
  IIRC Microsoft does share malware detection information with other antivirus providers, so that sounds plausible. (I think that's also part of the reason why Windows Defender appears less competitive in antivirus comparisons, since you'd have to be doing something wrong to perform worse than the baseline Microsoft gives you.)

viraptor 8y ago

Can't find the details now, but there were cases before of AVs using VirusTotal for getting their answers if they lacked any info / signatures for a binary. Could be what happened here, so they're not really independent. Edit: this describes the issue - https://mma.prnewswire.com/media/727967/VirusTotal_and_the_Comodo_Zeroday_Challenge_Black_Hat_2018.pdf https://mma.prnewswire.com/media/727967/VirusTotal_and_the_C...

cookiecaper 8y ago

AVs throw these all the time, for all kinds of applications and tools. They're triggered by patterns and signatures in the executable that "may indicate malicious behavior", etc., heuristically. It's in the AV vendor's interest to be overzealous and have lots of false positives rather than to have a single accidental false negative.

windwake12 8y ago

It's pretty common for programs compiled by "uncommon" compilers, and since the D compiler is selfhosted, it would fall into that category. AV software isn't magic, they probably just look for stack/calling/allocation patterns that don't look "right" meaning none of the major compilers generate such code, and it "might" be bad somehow. I've a few flags from npm with Kaspersky, because there's so many packages that include some little binary, and since this is npm, it's often "unusual", like go.

ynik 8y ago
The AV might not be even looking at patterns in the executable code. We've had an issue where we accidentally ran the msys strip tool over binaries compiled with the MSVC compiler. A quarter of the scanners on virustotal went crazy and "detected" our program. The same unstripped program was fine with them. And by "the same", I literally mean the same: virustotal showed that all sections in the "malicious" stripped executable had identical hashes to those in the clean unstripped executable. The only difference was some header bits that were irrelevant to the runtime behavior (I think it was the "linker version" field, and maybe some others).

drdrey 8y ago

They may not be as independent as you would think. For instance. There could be straight-up signature sharing or outsourcing between vendors, and there is definitely an incentive to flag something if your competitors also flag it.

vatueil 8y ago
IIRC Microsoft does share malware detection information with other antivirus providers, so that sounds plausible. (I think that's also part of the reason why Windows Defender appears less competitive in antivirus comparisons, since you'd have to be doing something wrong to perform worse than the baseline Microsoft gives you.)