-
-
Notifications
You must be signed in to change notification settings - Fork 801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Winget installation flagged as a trojan by windows security #5074
Comments
Flagged again for the "WezTerm-windows-20240203-110809-5046fc22.zip" version, but this time its "Trojan:Win32/Malgent!MSR" |
I'm also getting this from downloading |
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 |
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 |
Same issue here, it quarantines it after detecting some |
The issue is with |
As mentionned above, and as I have experienced myself, the issue arises also with winget. Would be nice to know precisely what is happening. |
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. |
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.
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/@[email protected]/111819639907704896 is a thread with more context. |
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" |
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:
Then unzip/copy to the Windows filesystem |
I have WezTerm installed via installer, not I submitted the file to Microsoft as a false-positive, and it's been closed with the following "analyst comment":
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.) |
@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. |
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 |
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/ |
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:
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. |
@statisch as this seems to be the primary issue for discussing this can we get this renamed to something like #5041 |
In particular, strip-ansi-escapes' dep graph is expanded by the overall set of enabled crate features when doing an indiscriminate `cargo build` vs. `cargo build -p strip-ansi-escapes`. This may help to avoid tripping over whatever is problematic in #5074
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 |
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. |
@JPHutchins thanks for the tip. Docs seems to be a weak point right now, but it sounds potentially interesting! |
This comment was marked as duplicate.
This comment was marked as duplicate.
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:) |
Yes, as stated above, this is resolved in the nightly build. |
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
The text was updated successfully, but these errors were encountered: