Trojan:Win32/Detplock reported by Windows Security #1308

giteasync commented

@lanzorg commented on GitHub:

I confirm the detection by Windows Security of a trojan with VSCodium.
No issue with Visual Studio Code.

@lanzorg commented on GitHub: I confirm the detection by Windows Security of a trojan with VSCodium. No issue with Visual Studio Code.

giteasync commented

@ppoetsma commented on GitHub:

Same here

@ppoetsma commented on GitHub: Same here

giteasync commented

@festum commented on GitHub:

This file blocking causing extensions not working properly.

@festum commented on GitHub: This file blocking causing extensions not working properly.

giteasync commented

@stripedpajamas commented on GitHub:

Well that sounds bad! Based on the filepath, it would seem Defender doesn't like https://www.npmjs.com/package/spdlog but I'm not sure why or why Visual Studio Code would not be detected.

I would suppose that it doesn't help VSCodium's "score" that the Windows binaries aren't signed, and the VSCode ones are. That (besides the license / telemetry differences) is the only significant difference I can think of between the two apps.

To everyone in this thread experiencing the issue: is there a workaround or is the application completely unusable for you?

@stripedpajamas commented on GitHub: Well that sounds bad! Based on the filepath, it would seem Defender doesn't like https://www.npmjs.com/package/spdlog but I'm not sure why or why Visual Studio Code would not be detected. I would suppose that it doesn't help VSCodium's "score" that the Windows binaries aren't signed, and the VSCode ones are. That (besides the license / telemetry differences) is the only significant difference I can think of between the two apps. To everyone in this thread experiencing the issue: is there a workaround or is the application completely unusable for you?

giteasync commented

@EricEon commented on GitHub:

I have the same problem today after updating. Hopefully the devs can inform us if there is a problem on their end or microsoft security is seeing a false positive.

@EricEon commented on GitHub: I have the same problem today after updating. Hopefully the devs can inform us if there is a problem on their end or microsoft security is seeing a false positive.

giteasync commented

@ijmac3 commented on GitHub:

I seem to have found a workaround: put the spdlog.node from the 1.42.0 zip in the spdlog folder and somehow it's working and not getting flagged by Windows Security!

This workaround worked for me too. Thanks.

@ijmac3 commented on GitHub: > I seem to have found a workaround: put the spdlog.node from the **1.42.0** zip in the spdlog folder and somehow it's working and not getting flagged by Windows Security! This workaround worked for me too. Thanks.

giteasync commented

@stripedpajamas commented on GitHub:

Additionally, can an affected user provide their copy of resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node so I can examine it? I will want to compare it with the non-Windows versions, as well as throw it at some other security scanners.

@stripedpajamas commented on GitHub: Additionally, can an affected user provide their copy of `resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node` so I can examine it? I will want to compare it with the non-Windows versions, as well as throw it at some other security scanners.

giteasync commented

@apollolux commented on GitHub:

I seem to have found a workaround: put the spdlog.node from the 1.42.0 zip in the spdlog folder and somehow it's working and not getting flagged by Windows Security! 7-zip is showing the 1.42.0 version as having a SHA-256 starting with 83B45F and the 1.42.1 version starting with BE3164. I don't know what the actual difference between the two files would be otherwise.

@apollolux commented on GitHub: I seem to have found a workaround: put the spdlog.node from the **1.42.0** zip in the spdlog folder and somehow it's working and not getting flagged by Windows Security! 7-zip is showing the 1.42.0 version as having a SHA-256 starting with 83B45F and the 1.42.1 version starting with BE3164. I don't know what the actual difference between the two files would be otherwise.

giteasync commented

@LaBaude32 commented on GitHub:

I seem to have found a workaround: put the spdlog.node from the 1.42.0 zip in the spdlog folder and somehow it's working and not getting flagged by Windows Security! 7-zip is showing the 1.42.0 version as having a SHA-256 starting with 83B45F and the 1.42.1 version starting with BE3164. I don't know what the actual difference between the two files would be otherwise.

Works for me too ! Thx !

@LaBaude32 commented on GitHub: > > > I seem to have found a workaround: put the spdlog.node from the **1.42.0** zip in the spdlog folder and somehow it's working and not getting flagged by Windows Security! 7-zip is showing the 1.42.0 version as having a SHA-256 starting with 83B45F and the 1.42.1 version starting with BE3164. I don't know what the actual difference between the two files would be otherwise. Works for me too ! Thx !

giteasync commented

@Archivist062 commented on GitHub:

Here is a copy of the inconveniencing file. It was also detected by Windows Defender on my system.

spdlog.zip

@Archivist062 commented on GitHub: Here is a copy of the inconveniencing file. It was also detected by Windows Defender on my system. [spdlog.zip](https://github.com/VSCodium/vscodium/files/4211989/spdlog.zip)

giteasync commented

spdlog_vscodium_1.42.0.zip

@kodx commented on GitHub:

I can confirm this bug.

Copy of spdlog.node from VSCodium 1.42.0 win x64 portable, not flagged as malicious by Windows Defender.

@kodx commented on GitHub: I can confirm this bug. Copy of `spdlog.node` from VSCodium 1.42.0 win x64 portable, not flagged as malicious by Windows Defender. [spdlog_vscodium_1.42.0.zip](https://github.com/VSCodium/vscodium/files/4215204/spdlog_vscodium_1.42.0.zip)

giteasync commented

@jtrv commented on GitHub:

I also got this while trying to download the 1.42.0 spdlog mentioned above:

@jtrv commented on GitHub: I also got this while trying to download the 1.42.0 spdlog mentioned above: ![image](https://user-images.githubusercontent.com/46337843/74757979-954acc80-522b-11ea-8548-13932de0367d.png)

giteasync commented

@jtrv commented on GitHub:

Here's the message I got from bitdefender, according to bitdefender it's Trojan.GenericKD.42592584 not sure if that helps at all but I thought I would post it here just in case.

@jtrv commented on GitHub: Here's the message I got from bitdefender, according to bitdefender it's Trojan.GenericKD.42592584 not sure if that helps at all but I thought I would post it here just in case. ![image](https://user-images.githubusercontent.com/46337843/74756173-076de200-5229-11ea-9fa9-bcc40b4f7853.png)

giteasync commented

@kodx commented on GitHub:

I also got this while trying to download the 1.42.0 spdlog mentioned above:

Virustotal my archive with full path report:
https://www.virustotal.com/gui/file/f6a3e2c0ee51bdd2d3d13e2b24ec476ddfc4a5a93cc85e1bde64c4b68f90762e/detection

virustotal single file spdlog.node report:
https://www.virustotal.com/gui/file/83b45f3855234ad7127f816df6cdeef18f6631317a39f4bfbd13ef85484dae59/detection

My guess - file path is flagged, not the file itself.

@kodx commented on GitHub: > I also got this while trying to download the 1.42.0 spdlog mentioned above: > ![image](https://user-images.githubusercontent.com/46337843/74757979-954acc80-522b-11ea-8548-13932de0367d.png) Virustotal my archive with full path report: https://www.virustotal.com/gui/file/f6a3e2c0ee51bdd2d3d13e2b24ec476ddfc4a5a93cc85e1bde64c4b68f90762e/detection virustotal single file `spdlog.node` report: https://www.virustotal.com/gui/file/83b45f3855234ad7127f816df6cdeef18f6631317a39f4bfbd13ef85484dae59/detection My guess - file path is flagged, not the file itself.

giteasync commented

@stripedpajamas commented on GitHub:

Thank you all for your patience with this so far. Some updates/references:

spdlog.node file from 1.42.1 zip: https://www.virustotal.com/gui/file/be316480660f832c5d8d7d6a2d794708925323c39254a65e7b53e697893acbfe/detection

spdlog.node file from 1.42.0 zip: https://www.virustotal.com/gui/file/83b45f3855234ad7127f816df6cdeef18f6631317a39f4bfbd13ef85484dae59/detection

I don't see any significant changes in the vscode repo between 1.42.1 and 1.42.0: https://github.com/microsoft/vscode/compare/1.42.0%E2%80%A61.42.1

And no updates have landed in the actual spdlog repo since Nov: https://github.com/microsoft/node-spdlog/commits/master

Nothing out of the ordinary happened during the 1.42.1 win32 VSCodium build (not sure if this log is publicly accessible, hoping that it is): https://dev.azure.com/vscodium/ed707451-9762-44df-8afc-12fe5bf926e7/_apis/build/builds/612/logs/30

Build-time compilation of native node modules has always been a bit flaky, but I've never seen the produced files cause red-flags with security scanners. Native modules are different for OS/arch/node version combinations, and I do say that sometime in November, MS started using Node 12 (while VSCodium is still using Node 10): 14c3b2e486 (diff-cc8a2965e27fe75945ee81cba2157e0d). This would affect the produced spdlog.node file, but I still don't have an answer as to why a "malicious" spdlog.node file was produced.

Next steps:

I ~~will be examining~~ have examined the system and user installs' spdlog.node file and they are both the same hash and therefore also seen as malicious
I ~~will send~~ have sent up a PR to use Node 12 for our builds to better align with what MS is doing in their builds. I am confirming the produced spdlog.node files are not flagged as malicious before merging in.

@stripedpajamas commented on GitHub: Thank you all for your patience with this so far. Some updates/references: spdlog.node file from 1.42.1 zip: https://www.virustotal.com/gui/file/be316480660f832c5d8d7d6a2d794708925323c39254a65e7b53e697893acbfe/detection spdlog.node file from 1.42.0 zip: https://www.virustotal.com/gui/file/83b45f3855234ad7127f816df6cdeef18f6631317a39f4bfbd13ef85484dae59/detection I don't see any significant changes in the vscode repo between 1.42.1 and 1.42.0: https://github.com/microsoft/vscode/compare/1.42.0%E2%80%A61.42.1 And no updates have landed in the actual spdlog repo since Nov: https://github.com/microsoft/node-spdlog/commits/master Nothing out of the ordinary happened during the 1.42.1 win32 VSCodium build (not sure if this log is publicly accessible, hoping that it is): https://dev.azure.com/vscodium/ed707451-9762-44df-8afc-12fe5bf926e7/_apis/build/builds/612/logs/30 Build-time compilation of native node modules has always been a bit flaky, but I've never seen the produced files cause red-flags with security scanners. Native modules are different for OS/arch/node version combinations, and I do say that sometime in November, MS started using Node 12 (while VSCodium is still using Node 10): https://github.com/microsoft/vscode/commit/14c3b2e4865d32e8755fd2e71a42ca2a7d27d2e5#diff-cc8a2965e27fe75945ee81cba2157e0d. This would affect the produced spdlog.node file, but I still don't have an answer as to why a "malicious" spdlog.node file was produced. Next steps: - I ~~will be examining~~ have examined the system and user installs' spdlog.node file and they are both the same hash and therefore also seen as malicious - I ~~will send~~ have sent up a PR to use Node 12 for our builds to better align with what MS is doing in their builds. I am confirming the produced spdlog.node files are not flagged as malicious before merging in.

giteasync commented

@stripedpajamas commented on GitHub:

My guess - file path is flagged, not the file itself.

Any suggestions on a path forward if this is the case ?

@stripedpajamas commented on GitHub: > My guess - file path is flagged, not the file itself. Any suggestions on a path forward if this is the case ?

giteasync commented

@apollolux commented on GitHub:

For what it's worth, I personally believe it's been false positives all along likely due to one or more recent definitions/signatures updates to Windows Security and/or various antivirus apps that may coincidentally have similar release timing.

@apollolux commented on GitHub: For what it's worth, I personally believe it's been false positives all along likely due to one or more recent definitions/signatures updates to Windows Security and/or various antivirus apps that may coincidentally have similar release timing.

giteasync commented

@stripedpajamas commented on GitHub:

I've confirmed that freshly generated spdlog.node (with Node 12, as a part of #335) is still flagged: https://www.virustotal.com/gui/file/3f7d1ead6d98ad5366b454fff494a70568dfd34bc669c10b991c12c46627e1b7/detection

I will be investigating code signing after build to see what difference that will make. Other suggestions welcome; it looks bad to be flagged by antivirus 😞

@stripedpajamas commented on GitHub: I've confirmed that freshly generated spdlog.node (with Node 12, as a part of #335) is still flagged: https://www.virustotal.com/gui/file/3f7d1ead6d98ad5366b454fff494a70568dfd34bc669c10b991c12c46627e1b7/detection I will be investigating code signing after build to see what difference that will make. Other suggestions welcome; it looks bad to be flagged by antivirus 😞

giteasync commented

@kodx commented on GitHub:

I will be investigating code signing after build to see what difference that will make. Other suggestions welcome; it looks bad to be flagged by antivirus 😞

Another option would be contacting an AV companies to remove this path from bases, but it would be a lot of work and may be useless(they can just reject any requests).

Maybe contact another open source developers to ask them, how they fix similar problems if have any?

@kodx commented on GitHub: > I will be investigating code signing after build to see what difference that will make. Other suggestions welcome; it looks bad to be flagged by antivirus 😞 Another option would be contacting an AV companies to remove this path from bases, but it would be a lot of work and may be useless(they can just reject any requests). Maybe contact another open source developers to ask them, how they fix similar problems if have any?

giteasync commented

@stripedpajamas commented on GitHub:

@apollolux I am assuming the same, since there is nothing malicious in spdlog.node etc.

Suggested in #174 was that signing the code would give us better chances of not being flagged by AV, but I haven't had time to implement that yet.

@stripedpajamas commented on GitHub: @apollolux I am assuming the same, since there is nothing malicious in spdlog.node etc. Suggested in #174 was that signing the code would give us better chances of not being flagged by AV, but I haven't had time to implement that yet.

giteasync commented

@stripedpajamas commented on GitHub:

@Rondom do you know the process to report false positives for Windows Defender? I'm a mac user so have very little context here.

@stripedpajamas commented on GitHub: @Rondom do you know the process to report false positives for Windows Defender? I'm a mac user so have very little context here.

giteasync commented

@TroySchmidt commented on GitHub:

Here is something interesting. I deleted it and when I downloaded the zip file Windows Defender caught it. I marked it as accepted and then restored the UserSetup install. Since then it hasn't flagged the installed VSCodium User Setup the second time around yet.

@TroySchmidt commented on GitHub: Here is something interesting. I deleted it and when I downloaded the zip file Windows Defender caught it. I marked it as accepted and then restored the UserSetup install. Since then it hasn't flagged the installed VSCodium User Setup the second time around yet.

giteasync commented

@Therealskythe commented on GitHub:

That's very scary stuff. I chose to delete the file and after a restart, my Project Manager extension stopped working.

I wanted to support this project but first day I get virus alarm and important addons stop working? Sorry, I need this for work. I'm back to VSC.

@Therealskythe commented on GitHub: That's very scary stuff. I chose to delete the file and after a restart, my Project Manager extension stopped working. I wanted to support this project but first day I get virus alarm and important addons stop working? Sorry, I need this for work. I'm back to VSC.

giteasync commented

@Rondom commented on GitHub:

Microsoft reacts quite quickly to reports of false positives, so reposting it is definitely the way to go!

@Rondom commented on GitHub: Microsoft reacts quite quickly to reports of false positives, so reposting it is definitely the way to go!

giteasync commented

@stripedpajamas commented on GitHub:

Totally understandable, @Therealskythe . Definitely deleting the false-positive file will result in degraded functionality, so that makes sense.

@stripedpajamas commented on GitHub: Totally understandable, @Therealskythe . Definitely deleting the false-positive file will result in degraded functionality, so that makes sense.

giteasync commented

@sub6as commented on GitHub:

I'm also having similar issues with bitdefender, so I've submitted a link to VSCodiumSetup-x64-1.42.1.exe as false positive to them. Hopefully that fixes it.

Update: automated reply here

Dear Arran Short, 

Thank you for your file submission.

The file has been automatically sent to our laboratories for specialized analysis. If the file is indeed a False Positive, the detection will be removed in the next 72 hours and the modification will be implemented in the product through a Signature Update. Please keep your Bitdefender up-to-date.

Please be informed that this is an automated process. Reply to this email if you have any other issues regarding your Bitdefender product and one of our engineers will take over.

Have a nice day!

@sub6as commented on GitHub: I'm also having similar issues with bitdefender, so I've submitted a link to VSCodiumSetup-x64-1.42.1.exe as false positive to them. Hopefully that fixes it. Update: automated reply here ``` Dear Arran Short, Thank you for your file submission. The file has been automatically sent to our laboratories for specialized analysis. If the file is indeed a False Positive, the detection will be removed in the next 72 hours and the modification will be implemented in the product through a Signature Update. Please keep your Bitdefender up-to-date. Please be informed that this is an automated process. Reply to this email if you have any other issues regarding your Bitdefender product and one of our engineers will take over. Have a nice day! ```

giteasync commented

@super0xbad1dea commented on GitHub:

Feedback from Microsoft
Analyst comments:

We have removed the detection. Please follow the steps below to clear cached detection and obtain the latest malware definitions.

Open command prompt as administrator and change directory to c:\Program Files\Windows Defender
Run “MpCmdRun.exe -removedefinitions -dynamicsignatures”
Run "MpCmdRun.exe -SignatureUpdate"

Alternatively, the latest definition is available for download here: https://www.microsoft.com/en-us/wdsi/definitions

Thank you for contacting Microsoft.

@super0xbad1dea commented on GitHub: Feedback from Microsoft Analyst comments: We have removed the detection. Please follow the steps below to clear cached detection and obtain the latest malware definitions. 1. Open command prompt as administrator and change directory to c:\Program Files\Windows Defender 2. Run “MpCmdRun.exe -removedefinitions -dynamicsignatures” 3. Run "MpCmdRun.exe -SignatureUpdate" Alternatively, the latest definition is available for download here: https://www.microsoft.com/en-us/wdsi/definitions Thank you for contacting Microsoft.

giteasync commented

@stripedpajamas commented on GitHub:

Yeah I had a similar experience on a test machine, after "allowing" and redownloading, the zip, user, and system setups behaved properly and Defender didn't flag anything.

Still I am curious if there is an option to report the false positive more broadly.

@stripedpajamas commented on GitHub: Yeah I had a similar experience on a test machine, after "allowing" and redownloading, the zip, user, and system setups behaved properly and Defender didn't flag anything. Still I am curious if there is an option to report the false positive more broadly.

giteasync commented

@stripedpajamas commented on GitHub:

Thank you both @sub6as @super0xbad1dea for reporting.

I don't think there is anything more on this issue we can do besides implement signing the build artifacts which is covered by #174

If there are no objections, I'll close this issue out and focus on setting up the code signing.

@stripedpajamas commented on GitHub: Thank you both @sub6as @super0xbad1dea for reporting. I don't think there is anything more on this issue we can do besides implement signing the build artifacts which is covered by #174 If there are no objections, I'll close this issue out and focus on setting up the code signing.

giteasync commented

@super0xbad1dea commented on GitHub:

Uploaded the file to Microsoft and waiting for response:

File Hash (SHA256): BE316480660F832C5D8D7D6A2D794708925323C39254A65E7B53E697893ACBFE

@super0xbad1dea commented on GitHub: Uploaded the file to Microsoft and waiting for response: ![image](https://user-images.githubusercontent.com/47813926/74923654-77b76780-53d1-11ea-9132-2c4f36df6b7b.png) File Hash (SHA256): BE316480660F832C5D8D7D6A2D794708925323C39254A65E7B53E697893ACBFE

giteasync commented

@apollolux commented on GitHub:

I would assume so, unless it does some aggressive caching or doesn't update often. Unfortunately that means that those of us who can't perform the manual update have to wait for Defender to trigger it or find a way to trigger it within the Defender app.

@apollolux commented on GitHub: I would assume so, unless it does some aggressive caching or doesn't update often. Unfortunately that means that those of us who can't perform the manual update have to wait for Defender to trigger it or find a way to trigger it within the Defender app.

giteasync commented

@stripedpajamas commented on GitHub:

@apollolux wouldn't Windows Defender receive the updated definitions when it next checks for updates with MS?

@stripedpajamas commented on GitHub: @apollolux wouldn't Windows Defender receive the updated definitions when it next checks for updates with MS?

giteasync commented

@apollolux commented on GitHub:

I reported in the very first post that running the MpCmdRun.exe update procedures DO NOT WORK if you can't take ownership of the file. Manual definitions update is NOT a guarantee.

@apollolux commented on GitHub: I reported in the very first post that running the MpCmdRun.exe update procedures DO NOT WORK if you can't take ownership of the file. Manual definitions update is NOT a guarantee.

giteasync commented

@EricEon commented on GitHub:

Well, after updating the definitions for windows security and reinstalling version 1.42.1, no more notifications identifying spdlog.node as a trojan.

@EricEon commented on GitHub: Well, after updating the definitions for windows security and reinstalling version 1.42.1, no more notifications identifying spdlog.node as a trojan.

giteasync commented