0

I'm supporting a 32-bit, MFC-based application. For deployment to customers an MSI installer file is created via Visual Studio 2015. I have some customers reporting that the cannot install the application due to Microsoft Defender reporting a severe warning:

Exploit:O97M/CVE-2017-11882.JR!MTB

On my side, Norton Internet Security shows all the files to be clean. MalwareBytes also shows all files to be clean. How do I prevent this warning from showing up on my customer side?

Mark Malburg
  • 125
  • 1
  • 9
  • 1
    Do you have a code-signing certificate you can add to the MSI files? That *may* help. – Adrian Mole Feb 12 '21 at 15:53
  • The main application relies on unsigned 3rd party DLLs. Is it possible to sign an MSI which installs an unsigned application? – Mark Malburg Feb 12 '21 at 15:55
  • Yes. You can sign the .msi file in the same way as any other 'executable'. – Adrian Mole Feb 12 '21 at 15:55
  • The studio "Deployment Project Properties" doesn't seem to show an option for a signature/key file. Is there an easy way to integrate signing into the project? – Mark Malburg Feb 12 '21 at 15:58
  • Depending on the nature of your deployment project, there'll be a "post build command" option somewhere; you can add the required `signtool` command in that. – Adrian Mole Feb 12 '21 at 18:11
  • It's a curious detection though, I assume it's related to - https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2017-11882. I think I would create an exclusion, put the MSI file into the excluded folder so you can work with the file. Then extract all resources from the msi, dump each of the resources from the binary table using Orca if you have to, If you copy all the individual resources from the file into a non-excluded directory do any of them getting picked up in the same way, or is it the actual MSI that is detected? Sounds like a FP to me. – HelpingHand Feb 12 '21 at 21:29
  • 2
    This is an old topic and it seems it's not gonna bet better any time soon - here is how we do it for every monthly release: https://www.advancedinstaller.com/antivirus-whitelisting.html – Bogdan Mitrache Feb 15 '21 at 07:38

2 Answers2

1

Digital Signing: The setup can obviously be infected on the end user's PC even if your original setup is not - or your own setup could contain real malware or a false positive. Digital signing can help a bit - as stated by others. A digital signature verifies that the setup has arrived unchanged from the vendor. Certificates are not 100% reliable, and they are also expensive if you get an EV certificate ("Extended Validation Certificate").

Signtool.exe: See this old answer: Odd 'Program name' when installing signed msi installer. For ad-hoc signing I suppose you can try the signwizard as shown here. For build automation you would want the full command line. I haven't tested that in a while, maybe try this answer.

Warning: Be careful not to sign malware! Obviously. Then you have: signed malware. In that sense it is proven - certified even - to come from you. Irony.

VirusTotal.com: You should run scan on all binaries by zipping them and uploading to virustotal.com as your first step. This is screening for both malware and false positives. Sometimes I try the Kaspersky checker too. ESET has a free scan feature for your computer (not uploaded files): https://www.eset.com/int/home/online-scanner/ and also a "SysInspector" tool which can help diagnose potential infections on any computer.

SmartScreen: Windows Defender includes SmartScreen - a trust-based feature which flags setups that are unknown, unsigned and deemed unsafe. Here is some information: Windows Installer, Digital Certificates and SmartScreen

See these existing answers:

Process Explorer: A nifty feature of Process Explorer from Sysinternals / Microsoft is the ability to scan every process on your computer and using VirusTotal.com from inside the tool. See this video. Here is a screenshot of the tool in action - it has found malware running on the PC:

Process Explorer

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
0

Thanks for all of the ideas.

The problem seemed to go away with signing via adding this command to the "PostBuildEvent"

"C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe" sign /a $(BuiltOuputPath)

Mark Malburg
  • 125
  • 1
  • 9