dist: go1.7.4 windows/386 trace.exe detected as Trojan

[rsc]

We received a report at security@golang.org (thanks to Eitan Caspi) that:

I download now go1.7.4.windows-386.msi from https://golang.org/dl/ and when installing it, my ESET NOD32 gave me this virus alert:

Module Real-time file system protection - Threat Alert triggered on computer X: C:\Go\pkg\tool\windows_386\trace.exe contains a variant of Generik.EPEHWUN trojan.

I wanted to check further so I expanded the setup file using 7-zip and scanned the target folder, which found the same for file "fil8FDFABC3A72CF7ED0F03F3149B59F8E9".

I uploaded the file to virustotal.com and it was flagged as trojan by many AV engines (27 out of 58 engines) - https://virustotal.com/en/file/cd4b6551da15d172a61f4cefcbba77c0fde1932fee9ab0879cb1cf126a5d39fd/analysis/

Please check this ASAP! (and better scan all binaries you distributed, after you will expand them)

For transparency and to give others a chance to comment or investigate, I am publishing the report (above) and my response (below).

We believe this is a false positive.

We have seen this before, as Go binaries are a bit different to most common executables and often anti-virus scanners get suspicious about them. In this case, Symantec thinks trace.exe is the "Fareit" trojan, which "...does not create any copies of itself." That being the case, it's hard to imagine how trace.exe could possibly be that trojan. On the other hand, if the AV programs indicated trace.exe to be infected with a virus (a program that reproduces itself by infecting other programs) then it's conceivable that an infected build environment could yield infected binaries.

I've built a few variants of the Go 1.7.4 toolchain on different systems and I get a varying number of "virus" detections in trace.exe from these. I suspect that the root cause for this is some malware actually does get written in Go, and then when the AV teams start looking for distinctive features of those binaries, they instead find features distinctive to Go instead of distinctive to the malware. I also spent a few hours comparing binaries built on various systems (including my Mac laptop) against the go1.7.4 distribution. If there really is a trojan hiding in the go1.7.4 trace.exe, it is exceedingly well hidden!

In the past we've had some success by reporting these false positives to the anti-virus vendors. In this case, it appears a significant number of AV programs are being overly sensitive. I'm not sure if there's some easy way to report this to all those vendors at once, but if there is then we should do so.

If anyone knows how to report false positives to these vendors for correction, please let us know.

[minux]

One potential solution is to sign each exe with Google's code signing certificate. We are already signing our Darwin packages, so perhaps we could do the same for the distributed Windows EXEs.

[rsc]

Does that help? If something is signed it's not a virus?

[minux]

I heard that it might help if it's detected as one of the "generic" trojans. Perhaps it worths a try on the trace.exe example before asking AV vendors to whitelist?

[alexbrainman]

Does that help? If something is signed it's not a virus?

Are you trying to apply logic here?

Alex

[mattn]

I tried this. Extracted trace.exe from msi and checked with Symantec AntiVirus Scan on Windows2012 Server 64bit. I didn't install the go17.

It didn't recognize as virus.

Symantec AntiVirus Scan use heuristic scan. If the users in the world didn't know the file, Symantec AntiVirus Scan often recognize it is virus. I don't make sure other AV's are same.

[as]

@minux

Do AVs avoid executables if they're signed? The MS digital signatures work well with installers, but signed exes are bizarre:

MS won't stop an EXE from being loaded if its signature is invalid unless the PE file's DLLCharacteristics bit vector sets IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY. This is rarely done. The bit vector itself isn't covered in the signature check, so you can clear the FORCE_INTEGRITY bit if you can alter the executable anyway, allowing it to be loaded.

[minux]

Last time I heard, when your executable get flagged as a "generic" trojan (generic trojan is basically very wild guesses and has a high false positive rate), signing it (esp. with a major software distributor's certificate) might help improving its score. They certainly won't avoid checking the binary (unless it's signed with a valid MS cert.). Let me guess the reason trace.exe gets flagged: trace.exe contains non-trivial HTML code snippets and it might be thought as an indication of adware or something. Of course, AV software is basically random oracles, and you can't really understand why they flag a piece of harmless code.

[rsc]

@minux Nice theory about the HTML, but I get wildly different AV results just by compiling trace.exe in a different directory. :-)

[davecheney]

@as

MS won't stop an EXE from being loaded if its signature is invalid unless the PE file's DLLCharacteristics bit vector sets IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY. This is rarely done. The bit vector itself isn't covered in the signature check, so you can clear the FORCE_INTEGRITY bit if you can alter the executable anyway, allowing it to be loaded.

So the signature is optional unless a bit is set in the binary saying the signature must be valid. But if you changed the bit in the binary to say don't worry about the signature check, then then signature would not match, but it's ok because the you said that its ok for the signature not to match.

I'm speechless.

[as]

@davecheney

Actually the bit vector is not even part of the signature computation. MS signatures aren't computed by hashing the binary straight-through. The algorithm hops over holes in the executable, one of them being the DLL_CHARACTERISTICS.

The effect is that neither the vendor nor end user can prevent altered executables from becoming processes after they are extracted from an MSI.