Winget installation flagged as a trojan by windows security

[isgkm]

What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20240203-110809-5046fc22

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

Trying to install with winget on a fresh windows 11 installation alerts windows security of a "Trojan:Win32/Wacatac.B!ml" and automatically quarantines it.

There is no nightly version available in winget.

To Reproduce

Type winget install wez.wezterm in cmd/powershell.

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

Full windows security log:

Detected: Trojan:Win32/Wacatac.B!ml
Status: Quarantined
Details: This program is dangerous and executes commands from an attacker.
Affected items:
file: C:\Users\user\AppData\Local\Temp\WinGet\wez.wezterm.20240203-110809-5046fc22\DOFEDD.tmp
file: C:\Users\user\AppData\Local\Temp\WinGet\wez.wezterm.20240203-110809-5046fc22\WezTerm-20240203-110809-5046fc22-setup.exe

[isgkm]

Flagged again for the "WezTerm-windows-20240203-110809-5046fc22.zip" version, but this time its "Trojan:Win32/Malgent!MSR"

[tankorsmash]

I'm also getting this from downloading https://objects.githubusercontent.com/github-production-release-asset-2e65be/120568143/609f4929-1353-4ee8-9ca7-4f255c73eb45?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20240225%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240225T225642Z&X-Amz-Expires=300&X-Amz-Signature=d9cd3ec6bae58e0df77015c03e1e4b57be483ffd969cf5b23348833de18d1d7f&X-Amz-SignedHeaders=host&actor_id=1312390&key_id=0&repo_id=120568143&response-content-disposition=attachment%3B%20filename%3DWezTerm-20240203-110809-5046fc22-setup.exe&response-content-type=application%2Foctet-stream via https://wezfurlong.org/wezterm/install/windows.html on Windows 10

[zyrif]

winget upgrade fails for the same reason (win 10).
Interestingly, virustotal found no issues with this file (one vendor flagged it as suspicious, and that's it).

[igorzhilin]

It was flagged by a few dubious antiviruses as having a trojan. Nonetheless, would love to hear the author's opinion.

https://www.virustotal.com/gui/file/35a6ec0eff7aa65e3987f14223bfb9df831eaab2964eb441ed6cad4356d252ff
8 / 70 security vendors and no sandboxes flagged this file as malicious

[kungp]

Winget managed to install this on one of my Windows 10 machines a couple of days ago, but if I scan the file now it reports a trojan. Windows 11 refuses, says it's some "AgentTesla" trojan. Scanned the 10 machine with mwb and defender and it finds nothing, but I'm still pretty concerned...

Update: it does find it in strip-ansi-escapes.exe in the root WezTerm directory.

Update again: #5041

[peikk0]

Same issue here, it quarantines it after detecting some Trojan:Win32/AgentTesla!ml.

[abhbh]

The issue is with strip-ansi-escapes.exe reported earlier in #5041
If you download the .zip file from Releases, Windows will specifically block that executable.

[LucCADORET]

The issue is with strip-ansi-escapes.exe reported earlier in #5041 If you download the .zip file from Releases, Windows will specifically block that executable.

As mentionned above, and as I have experienced myself, the issue arises also with winget. Would be nice to know precisely what is happening.

[tankorsmash]

I'm a little concerned that this has not been acknowledged yet. Wezterm is otherwise trustworthy right? I haven't used it before this issue.

[isgkm]

I'm a little concerned that this has not been acknowledged yet. Wezterm is otherwise trustworthy right? I haven't used it before this issue.

I got fed up with windows and switched back to linux eventually and currently am using wezterm, so I don't actually care about this problem anymore, but I highly doubt it's anything serious. It's a huge project with 250+ contributors and even more users, supporters etc.

[wez]

These sorts of false positives pop up from time to time; you can see from searching in this repo the prior events. They are outside of my control and sort themselves out after someone reports the false positive.

You might have better luck with the nightly build.

I'm a little concerned that this has not been acknowledged yet. Wezterm is otherwise trustworthy right? I haven't used it before this issue.

Everything in wezterm is open source, and the CI is also open source. You can see exactly what has gone into a build and verify that there is nothing nefarious happening here, to the binaries that you download from this github repository.

If you are installing via some external aggregator/distro then the chain of trust is less clear.

It is currently "too difficult" for an independent OSS maintainer to automate code signing for windows executables; it's a ludicrous endeavor: I would need to found an LLC, have it independently verified, then fund annual book keeping for the LLC, its tax returns and status, just to get a code signing certificate that doesn't result in a scary prompt for the user. In addition, I have yet to find a certificate provider that will integrate nicely with GH actions in a fully automated way (most require some kind of USB hardware device or cloud call that requires a presence check in order to sign), so that implies that I therefore also need to procure and maintain a dedicated windows build system to produce these binaries and keep pressing a button on each build run.

I would love for this situation to be different!

https://fosstodon.org/@voltagex@aus.social/111819639907704896 is a thread with more context.

[igorzhilin]

it seems to be resolved now, i installed from winget the 0301 version, and no defender warnings anymore

[cprusprus]

it seems to be resolved now, i installed from winget the 0301 version, and no defender warnings anymore

@igorzhilin How? winget search wezterm shows: "WezTerm wez.wezterm 20240203-110809-5046fc22 winget"

[yooakim]

Sorry to report that the issue is back again.

But I fully sympathize with the issues you are facing @wez - so thanks for trying!

One things that can help is to download the file in the WSL2 session, so try doenload using curl in WSL:

curl -LO https://github.com/wez/wezterm/releases/download/20240203-110809-5046fc22/WezTerm-windows-20240203-110809-5046fc22.zip

Then unzip/copy to the Windows filesystem /mnt/c/Users<youruser> - then you can unblock the WezTerm files from Windows Defender.

[tmercswims]

I have WezTerm installed via installer, not winget, and strip-ansi-escapes.exe got flagged by Windows Defender as a "Trojan:Win32/Malgent!MSR."

I submitted the file to Microsoft as a false-positive, and it's been closed with the following "analyst comment":

We have determined that the files meet our criteria for malware. At this time the detection will remain in place.

So no luck getting this reversed for now, I guess.

(Not that I'm concerned, personally, for the record; I will continue to use WezTerm worry-free! Just annoying that MS continues to be wrong about this.)

[abelcheung]

@tmercswims It's quite odd for you to still get it flagged right now, because I have downloaded the 0203 installer yesterday. Fed it into Windows Defender, and no malware warning at all. It used to be full of red alerts back in the days (around end of Feb), but not now.

[AyoungDukie]

We recently enabled Windows Defender for our work machines (while previously using a third party AV tool), and I recently got bit by this. Supposedly everything is up to date, so this matches what @tmercswims experienced and seems to hold on latest definitions for Win11 12H2

Screenshots

Defender screenshots:

[tankorsmash]

blind speculation, but could this be related? I couldn't find xz packaged here, but maybe there's a dep or something that got caught in the crossfire? https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

[mitchcapper]

at 29 of 72 vendors flagging this: https://www.virustotal.com/gui/file/ac6b05ae682c120778791eb942895db8fe1e513787c718df6996a3895d82c1c3

that is a really high false positive rate. It also seems in the past the same binary is the primary issue getting flagged. The point of the utility is to simply strip ansi sequences from input while leaving CR/LF/HT (horizontal tab). Given this seems very basic can we not just rewrite this either directly in rust or c/c++?

there are well known regex to do the same including:

/(\x9B|\x1B\[)[0-?]*[ -\/]*[@-~]/
or more commonly found:
[\u001B\u009B][[\\]()#;?]*(?:(?:(?:[a-zA-Z\\d]*(?:;[a-zA-Z\\d]*)*)?\u0007)|(?:(?:\\d{1,4}(?:;\\d{0,4})*)?[\\dA-PRZcf-ntqry=><~])

Clearly with a live stream of data and avoiding buffering may take a bit more tweaking to use the regex on, assuming staying in rust: rust-lang/regex#425 may be required. Then again this isn't crazy functionality so could be done without regexs to more easily support streaming in rust.

strip-ansi-escapes is also pretty huge, at 1.2 megs for the binary. For comparison, me compiling sed statically with all features enabled on windows is 519kb. Gawk statically 912kb. Both of these would seem to handle far more complex situations then strip-ansi-escapes.

I will say compiling 5046fc2 in release generated a fairly different binary from the package stripped-ansi-escapes but that could be due to w/e optimizations etc.

[mitchcapper]

@statisch as this seems to be the primary issue for discussing this can we get this renamed to something like #5041 strip-ansi-escapes.exe is detected as a Trojan by some anti-virus causing installs to be flagged

[wez]

I made an adjustment to the CI in 4de4061 which slims down the deps (cargo will compute the superset of all enabled crate features when building multiple crates at once, and apply those to all of the crates) which seems to help the overall assessment:

https://www.virustotal.com/gui/file/59ecd511fe692bf3c90f6d038bbe1dbea97ad8d95e9ca38668b1e72c4e31b0e2

[Welding-Torch]

I can't even download the zip file for Wezterm. Windows literally blocks the download.

[JPHutchins]

It is currently "too difficult" for an independent OSS maintainer to automate code signing for windows executables;

I believe MS wants to remedy this situation for OSS. I reached out to the Azure Code Signing team and they were very supportive; I haven't validated all of the tooling yet, but I do want to make OSS contributors aware in case any one has some spare time to investigate - particularly, setting up signing in GitHub workflows would be very valuable for OSS.

[wez]

@JPHutchins thanks for the tip. Docs seems to be a weak point right now, but it sounds potentially interesting!

[mitchcapper]

Keep in mind nothing requires you to use this specific version, you can use the one from a few days earlier: https://github.com/wez/wezterm/releases/tag/20240128-202157-1e552d76

or the nightly installer that already has the cargo stripping from above: https://wezfurlong.org/wezterm/install/windows.html

that may also resolve it for you:)

[wez]

Yes, as stated above, this is resolved in the nightly build.
Continuing to try to use the prior release build which MS refuse to reclassify is just adding noise here.