Nim and Go programs identified by Carbon Black as malware on Windows | Hacker News Reader

Nim and Go programs identified by Carbon Black as malware on Windows

forum.nim-lang.org

209 pointssynergy20174 comments

There seems to be a lot of confusion in the comments about what's going on here.

1. The problem is occurring primarily with Carbon Black, a third-party product acquired by VMWare a few years ago. Microsoft is not involved.

2. This has nothing at all to do with code signing.

3. Carbon Black is part of the category of "next generation antivirus" which are notorious for false positive problems. It relies heavily on cloud-based machine learning heuristic techniques to identify "malware-like" behavior. It's fairly well known in the industry that these methods are prone to mislearning uncommon runtimes and compression/obfuscation tools as malware.

4. Vendors of these products usually suggest that the false positive problem will be mitigated by the corporate security operations center reviewing and dismissing alerts, but in practice most corporations configure the product very conservatively and do not invest the resources in managing the false positives.

"AI powered heuristics" are so frustrating in AV. "This program runs on the CPU. Malware often runs on the CPU! It must be malware!"

They advertise high detection rates, but the secret is just flagging everything as malware - and thus also catching the sample malware in a stopped-clock-is-sometimes-right kind of way

What does "runs on the CPU" mean in this context? Don't all programs "run on the CPU"?

That is in fact the joke

I thought jokes on HN were forbidden by law?

No just by convention and a relatively high bar. Clever jokes get by, unclever ones are doubly downvoted.

That was their point, yes. These tools treat anything they see malware do as a potential signal of malware, without any consideration of what the activity is. Obviously they're not actually going to flag "running on a CPU" as a sign of malware, but it's a pretty reasonable parody of their methodology.

In my experience, most of these "cloud/advanced/ai" anti-virus tools will tag your executables if you use common open source packers (upx) or open source obfuscators. Using less common tools generally doesn't raise red flags (???), but you can often trick them into being okay with packed code if you sign it with an EV cert.

I had a Powershell script embedded in an executable I wrote in C. It launched Powershell as a sub-process and piped the script into standard input. Windows Defender thought my executable was some trojan (something like trojan:Win32/Wacatac.B!ml). So I gzipped the script as part of the build process, embedded the gzipped script instead, along with a single file decompression library, and decompressed it at runtime - now Windows Defender is okay with my program. Gosh, if I can do that, some malware author can too. If these “heuristic” detections are so easy to bypass, what’s the point?

To mark a checkbox on some security compliance form somewhere.

I double clicked on a js file inside a zip folder before by accident. It ran, did nothing, but I got an email from IT within hours saying I needed to wipe my device. It took a lot of convincing to avoid doing that.

God this makes me appreciate working in the only section of a company that allows unmanaged devices and allows users to image their machines with whatever they see fit.

I can't imagine the paranoia I'd feel with having spyware on my machine constantly calling home.

What why? That’s the typical configuration for very large corporations. Coping steps:

1. Do not use your work computer for personal data.

2. There is no step 2.

Its less about personal information and more that I'm never comfortable with constant observation, regardless of what I'm doing. I could be buying a bagel and feel uncomfortable with a camera or police officer.

Additionally, my work requires the ability to pivot quick with software and requires root access, hardware control, etc. I've regularly worked with coworkers in other areas of the company who spend a week setting up a workaround to the managed machine.

My colleagues and I all run personalized linux configurations and a typical managed machine would greatly hamper that. The company is large enough that the IT dept would not have time to manage all our exceptions so they just let us be.

It helps to look at it from the other direction as well: if you install the wrong NPM/PyPI package and something exfiltrates your corporate credentials, data, etc. how are you going to look if the managed device configuration would have stopped it? It's a change in how we think about computing but the old styles are not very secure and attackers have considerable experience exploiting those all or nothing security models. Having something which monitors unknown binaries being launched is the right choice for most people, and even developers really need some careful sandboxing (e.g. unless a new binary is in ~/Projects it's probably malware).

The other thing to consider: why should you care about what you work on being monitored? The most obvious reason is using work equipment for personal things, which is just a bad idea for a number of reasons starting with liability and data loss (e.g. if you get laid off, does anything get lost when your now-former employer does a remote wipe?). The other reason is if you don't have a good relationship with the security people, which is a social problem which needs to be addressed at a higher level since it'll show up in other areas, too. Rather than looking like you're being difficult or non-compliant, it's probably better to try to figure out what rules make sense - e.g. having some relationship with the endpoint monitoring people to get policy updates on a non-geologic time scale, having an official policy for who in IT security has access to data and how that's logged, etc. It's good to get that kind of thing nailed down before, say, the company gets hit with a lawsuit because one of the ITSec analysts thought it was okay to stalk that hot intern & spy on their personal web activity.

You can justify arbitrary security theater by only looking at the worst case scenario.

Do you justify constant GPSs surveilance because your work keys/cards might get stolen if you visit a bad neighbourhood? I hope not.

It's always a tradeoff of security vs. actually being able to do your job. Sure, a breach will cost a company but if you only have access to (mostly worthless) company "secrets" and no customer data then you really need to consider the likelyhood of having your data/credentials stolen, the cost that would have as well as the cost of the proposed security measures to your daily operation.

Something isn't security theater because you don't personally have the same threat model or exposure. Attackers can easily avoid traditional antivirus software so people with more aggressive security postures have switched to investigating or blocking any unknown executable following pretty standard advice in the field that it's not sustainable to try to enumerate all of the bad things in the world.

Someone running random JavaScript out of a downloaded ZIP file matches the signature of a lot of attacks, and almost no legitimate activity: that's a super common technique to use something built-in like JScript rather than their own binary which might be blocked, and even web developers never do that intentionally since their code is running in a browser or something else like Node.

> Sure, a breach will cost a company but if you only have access to (mostly worthless) company "secrets" and no customer data then you really need to consider the likelyhood of having your data/credentials stolen, the cost that would have as well as the cost of the proposed security measures to your daily operation.

Some other costs to think about:

1. If you have any sort of cloud credential on your system, how quickly can you spend money before someone revokes it?

2. Can your system be used to attack any internal infrastructure? Deploy something in the cloud for further attacks?

3. Can your system be used to phish other people at your company by, say, sending realistic messages? What about customers?

Now, it's true that you have to consider the impact on daily work but in this case it's pretty low unless your job actually is to run random downloads and at any organization over a certain size the majority of times that alert trips it's probably going to be something where the cost of the malware which people routinely try to run would be non-trivial, too, even if you just measured it in the time it takes to investigate and cleanup.

Thats interesting, my internal custom-designed red team malware does that exact same thing (js file in a zip). Except for the "does nothing" part. Once you click on it, I start a covert command channel in the background, using DNS.

(ohh and it bypasses carbon black too, because .js isn't an executable :) )

How can a js file execute by clicking it? I have never seen that happen. Did you bind the file extension somehow your self?

Yeah probably. I was a little surprised myself, but it is my dev machine so not that surprised

JScript (Microsoft's JavaScript dialect) can be used as a general purpose scripting language (in purpose similar to shell scripts or maybe VBA, but using JavaScript and ActiveX). And until you install your first code editor to map the file extension to, the default action on double click is to execute the script.

Or at least that used to be the case, not sure if this is still a thing in Windows 10/11.

Active Scripting, including JScript, still ships out of the box in Win11. The file extension association is also there, but I don't recall if it's active by default, or you get the "how would you like to open?" dialog first.

This is the default behaviour in Windows. It runs in the Windows Script Host as JScript (Microsoft's version of ECMAScript) and has access to basically anything Win32 the current user has, the same as macros in Office

CB is a family of security products that runs on Linux, Windows and MacOS - one particular product prevents binaries from running until they have been placed in an explicit allow list based on a hash signature. At least some of those "I changed my exe and now it won't run" sounds suspiciously like their machines are running that particular product.

I don't work in security, but I've had zero good experiences with the anti-virus vendor market in my small amount of interaction. These next-gen ones will tell you that you won't even know it's running because it's so efficient. It uses machine learning buzzwords to magically find intruders or viruses.

It's sad that these salesmen seem to have convinced lots of the right industry people that you really need them.

I work in security, and I've had zero good experiences with the anti-virus vendor market.

I can't think of a program more dangerous than one which intercepts and has option to receives every byte read from the filesystem -- while also having its own arbitrary network access ... the idea that employing such a tool could ever be better than _not_ having that tool is wrong at such a fundamental level that I don't understand how our computing society allows it to go on ...

If you have the latitude to architect things well it can work. Sadly, almost nobody does :(

> Microsoft is not involved.

In this case maybe not, but MS Defender doesn't like Nim (and Nimble), either[0][1].

[0] https://github.com/nim-lang/Nim/issues/18933

[1] https://forum.nim-lang.org/t/8196

Windows Defender often doesn't like Go programs either.

Not sure the current status but at least a few times a year I have Windows Defender flag Go programs I compiled myself locally as potential malware. This has happened as recently as November.

> 1. The problem is occurring primarily with Carbon Black, a third-party product acquired by VMWare a few years ago. Microsoft is not involved.

The posted thread links others concerning other tools' detections. This problem is widespread and affects the entire AV industry, including Microsoft's products. It also affects pretty much every browser via "Google Safe Browsing" - and Google certainly does not care any more about false positives than the AV vendors they source their detections from. Also, Google runs VirusTotal, which greatly widens the reach of these shitty AV tools. For some reason Google feels the need to hide that association.

> 2. This has nothing at all to do with code signing.

Perhaps. It shouldn't, but that doesn't mean that lazy AV writers won't consider signing as a signal that something is safe - after all, Windows itself does. There are at least many developers claiming that signing helps against false positive detections.

This has been a problem with many compilers that aren't MSVC. I had antiviruses claim issues with Free Pascal as well as less used C compilers.

My solution to this "problem" is to simply ignore it - there isn't anything i can do about it anyway - and tell anyone who asks that it is a false positive.

Though FWIW Windows Defender (or whatever the antivirus installed by default is called) so far never had a false positive. Perhaps other antiviruses are over-eager to justify their existence - and price - so they have an incentive to scare the clueless users.

mmh, so is using MSVC compiler a possible workaround?

Possibly, but note that this is a lack of encountering an issue, not that the issue doesn't exist. Also it limits you to MSVC, C/C++ and languages that can transpile to C/C++ via MSVC. This isn't something that, e.g. Free Pascal can do and when i use other C compilers is mainly to avoid MSVC :-P.

No, the workaround is a signed executable.

Is Nim trying to get a signed compiler?

It's not the compiler that has to be signed, it's the outputs.

Any Windows EXE can be signed. It doesn't matter what compiler you used. The problem here isn't actually anything specific to Nim or Go, it's rather, the underlying UNIX oriented culture in which developers rarely sign their binaries. It'd affect any language with that culture. The Go FAQ on virus detection doesn't even mention signing at all - no wonder they have such problems.

Ok, tell me then, how does a random person sign their binaries without paying through the nose and going through an extensive review process?

It's one thing for a developer to get to distribute apps on an app store full hog with no oversight, and even there app stores are onerous. It's another to stop users from running their own software. Calling that a cultural difference is way too much. Heck, teenage Bill Gates made money selling his own software without someone forbidding it running on their own computers, it'd be hard imagining microsoft being what it is if this is the environment we're leaving the next generation of young hackers.

CAs want to eat. Also antivirus doesn't prevent users from running a program, it just shows a scary looking message. The whole thing is just a drop in quality as viruses are a thing of the past since Vista and as a result antiviruses don't have enough funding to maintain quality.

"how does a random person sign their binaries without paying through the nose and going through an extensive review process?"

You just self sign. Conveyor does it by default, even. You can always run your own software on your own machine. Now, other people's Windows machines out of the box won't treat that as signed of course. Users would have to install your signing certificate. But you certainly can sign code without paying for it, it's just not meaningful to a fresh Windows install. Self signing is useful for distributing software internal to organizations for example.

To distribute more widely, well, neither OV nor EV is actually an extensive review process. Even for EV they just verify that you're actually buying a certificate by looking you up in a business directory and calling you via the published contact details. Nothing about your software is reviewed.

If signing actually prevents false positives then it's another problem with the AV tools - bad actors can get signing certificates easily enough, easier than a open source developer with 0 budget in fact.

It doesn't prevent false positives, it just means that once these tools learn that you're a legit organization you're much less likely to encounter them because it's a strong signal of goodness, especially so for EV keys that are harder to steal.

The biggest issue with this comes from people trying to use these languages in a work scenario where an over-eager antivirus that can't be disabled by the user would cause issues.

It's a balancing act to not trigger too many false positives while also not missing any malware. Hitting more false positives to also get more true positives can be a good thing when even one false negative can be destructive.

I don't think any AV wants to present false positives though. That's just annoying to users and they're going to disable the AV if it tries to tell them half the things that they download are viruses.

I've reported a false positive via the official Microsoft Security channel for it (it's a web form) and AFAIK it has been whitelisted. My suspicion is that this process is mostly automated, too, but it's worth giving it a try.

MSVC also gets false positives if the Windows libraries are statically linked to the compiled project. A painful irony that has made sharing an indie-game with test users quite difficult as it requires they install the VC++ redistributables.

You can ship VC++ redistributables as DLLs alongside your application without an installer. Not that you should have to.

> not that you should have to

On the contrary, every application should ship their dependencies!

Sure, but the best option for that is to statically link them (if they are only used by one binary and users swapping them out doesn't make sense). And you should be able to do that without third parties slandering you.

Windows Defender reports plenty of false positives, most recently for me with Pyinstaller (https://duckduckgo.com/?q=pyinstaller+windows+defender&ia=we...). They're all just bad.

A possible work around: is there any blessed assembler? Like can you tie into MSVC's assembler? This does sound kind of dumb but, idk.

Does LLVM work? Does is there a Nim frontend for LLVM? I guess you can always compile Nim into C as it was done in the past I believe.

> is there a Nim frontend for LLVM?

Yes there is. https://github.com/arnetheduck/nlvm

> My solution to this "problem" is to simply ignore it - there isn't anything i can do about it anyway - and tell anyone who asks that it is a false positive.

That works most of the time, but there are some orgs (e.g., US gov) where it will not.

Author of the OffensiveNim repo here.

This is a problem that's existed since the creation of the AV/EDR industry and is not going away as vendors have 0 motivation to address it. All programming languages have had to deal with this issue, this is definitely not targeted towards the Nim language.

- If you're a Nim developer trying to deploy a production app in a Windows environment: get a code signing cert and slap it on your application (signing the compiler won't help).

- If you're trying to develop a Nim app in an organization that has an EDR/AV deployed: you're going to have to talk with your friendly neighborhood security folks and work with them to whitelist the Nim compiler, tooling and folders where you work with Nim code.

You'll still be subjected to the EDR/AVs WinAPI hooking and behavioral heuristics even with the code signing cert and sometimes even after whitelisting depending on the product so you still might get issues were the AV/EDR is affecting your application but at least it won't straight up quarantine it and go ape shit.

EDIT: just to be clear, the root cause of this is the AV/EDR industry not doing due diligence. Unfortunately, I'm very skeptical of them doing anything about this as their entire business model revolves around "cast a wide net in the attempt to catch as many things as possible".

About antivirus on Windows, as a person who has shipped a commercial windows app that was regularly hit by anti virus. There is almost nothing you can do except wait. Windows antivirus companies mark your program as a virus when you .exe looks different from anything it saw before. The reports do come down after your .exe is shipped to thousands of computers and users unquarantine it manually. Signing the exe with windows keys or uploading your exe to special white lists does not work! We tried. It's just time and install base. Every update changes the exe and AV would flare up again.

Windows antivirus companies are basically a scam and are worse than the protection they offer. They are more likely to mine Bitcoin ( https://www.theverge.com/2022/1/7/22869528/norton-crypto-min... ) or man-in-the-middle ( https://www.thesafemac.com/avasts-man-in-the-middle/ ). Antivirus companies have become the bad actors they tried but failed to stop. (https://www.cbc.ca/news/science/antivirus-software-1.3668746 )

I recommend Nim does nothing with regards with AV as there is nothing it can do but wait...

10 years ago, my antivirus software on Windows flagged a program that I wrote myself, for my own use, as malicious. That was the day I instantly lost trust of all "antivirus" solutions and never touched one again.

It was usual more than twenty years ago already.

AVs often panic with any sockets or registry code.

Such a shame that innovative languages are hampered in getting users by the ineptitude of antivirus vendors.

What is innocative in go? Concurrency primitives? Single file?

Nothing wrong on iterating on what came before.

Sure, but it's also not really innovative to iterate.

When you think about it, is an automobile really an innovation compared to a horse cart ?

I would argue the innovation is the concept of a mechanical engine powering it rather than horses.

Cars are just one of the implementations, based off an iteration of the horse cart.

It's relative. Go is more like an automobile that often pretends to be a cart for the sake of simplicity. Compared to a horse cart, that's definitely innovative. Compared to other cars, not so much.

Go is more like an climate that pretends to be an atmosphere for simplicity. Compared to a greenhouse you really can. Compared to the other climates it's essentially sophistry.

This sort of comment is immature and doesn't help anyone.

Making things simpler to use is innovative to me.

classic HN hivemind opinion regurgitation

Is this a joke? I hate golang and have 99 bad things to say about it, but "not innovative" isn't going to be on that list.

Go had an FAQ entry for this because it happens so frequently.

https://go.dev/doc/faq#virus

Yeah I ran into this a couple years ago when I tried to distribute Windows binaries for a utility program I wrote. I seem to recall the issue being described in that since every Go binary comes pre-packaged with the Go runtime, all software -- including malware written in Go -- will have similar structure, and some common code.

I wasn't planning on monetizing the utility and I didn't expect a lot of people to use it so I just posted it with a disclaimer to ignore Windows Defender, and the source code was available on Github.

I assume this is the same racket that they had years ago where you need some certification (which you have to buy from one the their licensed companies) to sign all of your binaries OR you have to go through the Windows store.

It was pretty devastating for me a few years back because I spent a year and half making some software and then ended up with the best potential users accusing me of developing malware and being very hostile.

Also when I tried to get the certificate the company was a nightmare to deal with. Truly garbage people.

The whole thing is a racket. It's just another way for Microsoft to extract money.

Because they are a bunch of mafia goons.

Yet another reason why it should be illegal for the OS maker to also own a store for it (specifically a for profit one, if the term "store" isn't clear enough).

I am guessing that the situation got worse with the introduction of the Windows Store with Windows 8 ?

The most popular nim repository on Github except nim-lang itself is OffensiveNim which basically is a collection implementation of malware features in nim. It's a very popular language for red teamers. This has nothing to do with signed binaries.

So what’s the reason for Go? It too is eloquent enough to be able to write malware?

Golang binaries are had to analyze (or rather were, new tooling, etc). Assume vendors and automation are 5 years behind everyone else actually doing malware analysis by hand. Most of this blocking is probably running off of signatures and not behavior.

I haven't been involved in this area, so I truly have no horse in this race.

But avoiding malware strikes me as a hard-to-solve problem, particular for non-open-source software.

Is it possible that paid-for-certification is one of the last-bad known approaches?

Unless they are doing a code review, and security audit (actual Audit) then no it is just a cash grab and gate keeping

Yes, all certifications are just cash grabs - weather it is "organic" food, or "acme certified engineer" (replace acme with the megacorp or your choice), or pci or soc2 or ...

Certifying is a good business to be in, but deadly boring.

The point of code signing certificates is purely to establish developer identity. It says nothing about the code and in fact you can buy a signing certificate once and then sign as many binaries as you like without limit, automatically and locally.

Code signing in modern operating systems does the same thing as having a secure origin for web apps or a DKIM key for email: it ties code to a stable long term identifier controlled by a specific person or group of people. It doesn't say anything about whether the results are good or bad, which is why Windows still learns reputations over certificates. If you sign software and distribute malware it'll learn that and you'll get blocked.

With how eager developers seem to be pushing certification keys into public github repositories or open S3 buckets, it's almost easier for criminals to get a valid signing key than it is for honest developers, especially non-profit entities.

On top of that, the certification process isn't great either. Even honest certificate authorities have occasionally cut a corner too many and allowed malicious certificates to be printed; and there's some rather sketchy authorities that don't take the requirements too seriously. (StartCom e.g. offered to ignore the requirements for bribes years before they finally got removed from trust databases.)

So I don't think that certificates offer any security benefit. Might as well drop them.

Windows signing keys are often protected by hardware security modules (often on USB devices), so you can't push them to GitHub repositories.

Malware authors spend a lot of time trying to steal signing keys exactly to try and avoid AV detection, so it's not worthless. It's certainly not easier for criminals to get one than honest developers.

> Is it possible that paid-for-certification is one of the last-bad known approaches?

Too late to edit, but I meant to write "... least-bad ...".

It is possible there is malice of some sort involved.

However, it is also sufficient to observe that with the way signatures are often done, it is very easy for someone to write a virus signature against a minority compiler and accidentally write a signature that identifies the output of that compiler, or something that compiler is very likely to output, and not realize it, because all the test cases against the majority compiler executables in the test suite pass just fine.

One need not choose one or the other; an accident at the engineer level can be considered a wonderful thing at the business strategy level. But the issue of minority compilers creating target-rich environments for signature writers is a sufficient explanation.

(At least for a time; one would think by now the virus test suites would have a good sampling of Go executables by now....)

Game devs have similar issues. They need fairly wide API access, and if you don't ship inside of Steam, or have an exe generated from Unity or Unreal. Then SmartScreen (part of Defender?) will often flag you.

It's universal across the board, really, and it's been going of for a while. Nearly 10 years ago, I was doing MS office integration. Every new build of our addins got flagged by virus vendors. Norton in particular flagged us due to "reputation" which makes it sounds like you have a bad reputation, but what it actually means is not enough people have it installed, so they assume it must be a virus. Definitely makes it hard to gain traction as a small dev. We had to spend around 1k USD per year for the privilege of a code signing cert and had to jump through a bunch of hoops like submitting every build to Norton before we released. Very annoying and definitely a racket.

It costs a flat one-time $100 for each game you put on Steam, which is a bargain compared to anyone's code signing certificates. Plus you get auto updating and everything in Steamworks.

If you're remotely serious about indie game development, it's the way to go.

Don't forget the 30% platform fee from Steam.

There's something so gross about this comment (or maybe there's a better word for it?).

Valve is guilty of anti-competitive behavior, and effectively has a monopoly on PC gaming.

> If you're remotely serious about indie game development, it's the way to go.

It's basically impossible to be successful on PC without publishing on Steam. It's "the way to go" because there are no other real options, not because $100 is "a bargain".

AFAIK you can get around the SmartScreen with an expensive EV code signing certificate. For regular code signing certificate, SmartScreen will pop up until there are enough downloads to accumulate enough "reputation score" (which results in a chicken-egg-situation though).

Signing executables to prove where it came from is perfectly reasonable. Maybe Microsoft is going a bit far with how scary their warning messages for unsigned executables are, and how hard they are to dismiss, but the principle is sound.

The problem is that I somehow have to pay $300 to get a certificate, never mind the annoying process of doing it. All the issuer is doing is verify that a) my company exists and b) I'm allowed to act on my company's behalf. Both of these are public information in my country, and any intern can verify it in about 3 minutes. That's not worth $300, and smells like illegal price fixing.

Wait, how is microsoft extracting money if they don't sell you the certificates? I thought you could get any EV (I think it's EV, not sure though) certificate from any vendor.

I assume they are suggesting the EV’s have a kickback to MS.

However, that doesn’t seem to be the case. “Microsoft will not charge any fee for including a CA’s certificates in the Program.” https://learn.microsoft.com/en-us/previous-versions/cc751157...

That said, they do have a great deal of requirements that impose costs for 3rd party Audits etc.

Note: VMWare is not Microsoft. This is the tool in qeuestion:

https://www.vmware.com/products/carbon-black-cloud.html

Yeah, and https://forum.nim-lang.org/t/9850#64960 does mention false positives on Windows, for examples

Windows Defender detected Trojan.AndroidOS/Multiverze in Nim-1.6.10_64.zip https://forum.nim-lang.org/t/9744#64108

Trojan:Win32/Wacatac.B!ml

https://forum.nim-lang.org/t/7885#60008

These companies should be held legally responsible for defamation.

IIR, a malware developer or few has already tried suing AV makers for "defaming" their software.

There are many problems which an honest and competent legal system, working from timely and well-written laws, can ~cure. In the real world...the favorable adjectives are usually less applicable.

We spent weeks debugging a problem, which eventually we needed remote access to debug, that turns out Carbon Black replacing a WIN32 library with something that got a segv in a certain situation. This was in the startup of our system.

Once we found that out, we told them to call VMware. They ended up whitelisting us.

Complete shitshow.

You're assuming malice, but in this case there's a much more simple explanation: indifference.

VMware want to keep bad stuff off of their customers' machines, and they want to do so without pissing off their customers too much. Carbon Black is a "next gen" endpoint solution, meaning essentially that it uses some kind of ML model in addition to classic AV signatures. I don't know anything about their ML model, but I would guess that it is very probably tuned to slightly prefer false positives to false negatives.

With that background, imagine that a new language called FooBar gets invented. FooBar doesn't get a huge amount of traction for Windows and OSX apps, but pentesters take to it and FooBarRed becomes super popular. That means that the dataset that the ML model is being trained on doesn't contain a lot of FooBar, but when it does, the FooBar is always bad. Naturally, the model decides that as it has only ever tasted bad FooBar, all FooBar is bad.

That's "wrong" from a fairness standpoint, and the solution is for VMware to manually tune the model. But without customer complaints, they are not likely to do so. They're not acting maliciously; they just aren't incentivised to care.

And the signing software looks like it's like 20+ years old. Maybe more. AND, the USB keyfob they give you DOES NOT WORK via RDP. You have to use VNC to login to the console, otherwise the USB device is not seen. We have the key plugged into a machine in a data center.

Originally, I tried the USB forwarding from RDP, where I had it plugged in locally at my workstation (a Mac). The feature of forwarding devices exists in macOS MS RDP, but it doesn't work for the device I had.

It took me about a month of effort to get the EV code signing certificate to work. I'm pretty bitter about it.

Conveyor can solve that. It's a packaging tool that amongst other things can sign Windows binaries and packages from macOS and Linux, including with the USB key fobs you use with EV certificates. The UX is also better than standard signing tools - you configure it with a simple config file, it can show progress bars on the console etc. There's a video on the website.

https://hydraulic.software/

EV certificates tend to be quite trusted by AV vendors, even if you're new and never had any downloads before, because you have to go through more validation. OV certificates are cheaper and less work to get but start out with neutral trust, so your early downloads will get warnings that the binaries aren't downloaded very often.

The sort of AV problem is unfortunately quite common on Windows, partly because a lot of devs and especially the sort of UNIX-oriented devs that write Nim and Go programs simply won't sign their software. It's the nature of modern platforms: you either sign your software and build up reputation, like with sending email, or you don't and end up being hit by the full brunt of heuristic guessing (or on macOS, refusal to run at all without workarounds). Not signing on Windows is a bit like sending email without SPF or DKIM, it's going to land you in the spam folder a lot.

Thanks. When our current solution expires, I will look at this solution.

The USB issue is intentional and documented Windows feature (although so badly documented that it apparently surprises even MS insiders). IIRC it only behaves this way on Windows Server SKUs. (the idea is that when it is used as terminal server, each user may have their own similar device)

I doubt it's intentional. Less popular software often gets punished by AVs. Likely some malware samples that used the language (or included some tool/library written in it) got used to make a signature/heuristic automatically.

I understand that OS and browser vendors want to protect users from all kinds of exploits, but it's extremely annoying that essentially any new and unknown binary is treated as if it contained a virus.

Windows will show a warning dialog for essentially any unknown executable downloaded from the internet. The only way out of this is to buy a somewhat expensive EV code signing certificate and sign the binary. Or to have that binary become popular enough to get known, but then you have the same issue again after an update.

Chrome will tell users that "downloaded files are dangerous" if they are an unknown executable. So far I don't know any way around this warning, and users have to go to the full download page to override this. No idea how to get Chrome to trust this, maybe code signing helps here as well, but who knows.

And we're not even at false positives from anti-virus yet, those come on top of these problems.

>Windows will show a warning dialog for essentially any unknown executable downloaded from the internet.

Windows has done this since at least XP with any executable of remote origins (including other machines in LANs), regardless of digital signatures. Personally, I think this is fine so long as it is just a notification/warning and lets the user be on their way with a simple confirmation.

Blame stupid users who open anything and everything without a second thought.

The protections are in place because most users can't be trusted to have enough self-control and intelligence to question that attachment called VerifyYourPassword.exe from youronlineaccount@totallyrealchasebank.com

Users opening anything and everything is only a problem because Windows doesn't (or rather didn't, for a long time) have a package manager and "opening anything and everything" is the primary way to install applications.

Notice how I used an example that’s not remotely related to installing and using application?

I highly doubt that having a built in package manager starting in Windows 98 would have in any way shape or form affected how people interact with email attachments. They’re two completely different tasks and nothing about package management would really carry over. People are still going to want to read that super important attachment without a second thought even if they can install a package using Apt.

In fact, macOS has pretty much the exact same protections in the form of Gatekeeper, so it’s clearly not a Windows-only thing.

> Notice how I used an example that’s not remotely related to installing and using application?

GPs point was that users are trained by having to run random executables in order to install anything. That they are now conditioned into casually running other programs that are not installers is the result.

> I highly doubt that having a built in package manager starting in Windows 98 would have in any way shape or form affected how people interact with email attachments. They’re two completely different tasks and nothing about package management would really carry over. People are still going to want to read that super important attachment without a second thought even if they can install a package using Apt.

This is an argument for making opening something and running something distinct actions in GUI programs (including your mail reader, browser downloads and file explorer) so that a user trying to open something does not execute it by accident, not for the current AV industry. It just so happens that that's how things work in many Linux desktop environments.

> In fact, macOS has pretty much the exact same protections in the form of Gatekeeper, so it’s clearly not a Windows-only thing.

Apple, like Microsoft, also profits from making developers codesign their applications. They also both want to profit even more by making developers sell their applications through the OS app store where they can take a cut. Both of them engaging in this "security" bs is hardly an argument that they are doing it to protect their users.

but thats fine no? how far do you think the current approach is going to go?

* lets not allow them to run some program because it is dangerous * maybe just remove all programs that are not signed * actually, only programs that are signed by approved by us devs * not even them, we decide which program should the user install * maybe dont allow them to read email because its dangerous * ... allow them to press only specific keys on the keyboard in case they start entering a credit card, we must read all keys they press * listen to what they say in case they start talking with a dangerous person on the phone we must block the phone call

This is literally the slippery slope fallacy.

Calling something a fallacy does not make it one. Arguing for security without any other considerations has a predictable result: zero freedom.

Don’t blame users, blame society/technology for not providing adequate context to people do they can make safe decisions.

> I understand that OS and browser vendors want to protect users from all kinds of exploits

Meanwhile their own products are basically spyware.

There are two types of certificate on Windows: OV and EV. OV is easier to get and the key protection requirements are less strict, but your new identity starts out with no reputation. Browsers will warn you that the program is rarely downloaded until you pick up some reputation from users not reporting it as malware.

EV certs don't have that problem. Even for a new company or individual who has never distributed software to Windows before, user won't see any warnings. EV certs have a more thorough ID verification procedure, and keys have to be protected in hardware so you can't accidentally push them somewhere. Most CAs will physically mail you a USB dongle that you can use for signing.

Nonetheless, the unknown binary warnings will go away even if you use an OV cert as long as your early users are forgiving.

Our company has had EV-signed binaries flagged as malware by products from Symantec, F-Secure and Avast. Probably others too, those three I can remember off the top of my head.

Yes it's just a signal to AV engines, not a whitelist. Windows Defender is quite respectful of it. Something that can increase the risk of FPs is mixed signing. Like, not signing every DLL and EXE in the program with the same certificate, not signing the installers/packages, only signing the installers/packages and not the contents, etc.

Is this identified by windows or by a third party product? The thread seems to be about CarbonBlack?

Third party product, yeah.

Yeah, and in the same post https://forum.nim-lang.org/t/9850#64960 does mention false positives on Windows

Run into this problem when I distribute binaries at work to people who are using Windows.

Every time I was using a mingw tool chain to either compile c++ directly, or using it as part of something like Nikita to distribute python junk. Windows defender just stopped execution, some of the enterprise endpoint junk deletes the file entirely.

I just put in tickets with the AV products our company uses requesting they examine whu Go and Nim binaries are being flagged. We only have AV because of security theater, and are on all Linux and Mac infrastructure, but for what it is worth, sometimes a few tickets go a long way.

I have run into this when distributing go binaries to enterprises. We also found that many of the malware vendors share their heuristic-detected signatures with each other so once one decides your binary is malware things really go downhill.

We signed the exe with a standard code signing cert and the problems went away.

These days we use an EV code signing cert that have to have their private key in an HSM.

I had a lot of trouble years ago because the Digital Mars C/C++ compiler had its own runtime library. Many malware detectors would flag anything that didn't have the Microsoft C compiler runtime library in it as malware.

Fortunately, this problem has been cleared up.

My understanding is that this is caused by Nim/Go's stdlib or other program dependencies being identified as malware.

These languages are almost always built statically so the stdlib and other dependencies are always included in the program binaries and could trigger a false positive.

You can always make the "err on the safe side" argument for security related practice. But at least provide transparent and responsive communication channels for legitimate authors to dispute a flagging. Right now the whole malware detection thing is a blackbox that makes software authors feel powerless. I can only imagine AI products making this even worse.

Simply banning the language because the language is efficient and elegant to be used for malware is ridiculous.

That would be extremely stupid and shortsighted from them, to the point it makes one wonder it could be intentional. In the late 90s and early 2Ks a lot of cracking software, keygens etc. were made in Delphi, which i also used for years at different companies, and I don't recall a single antivirus complaining about executables compiled by me or any other colleague.

I suspect it's just an over-fitting problem. By some (likely ML-derived) metrics, Go and Nim binaries don't look like MSVC binaries.

My general feeling is that we're going to see many years of ML over-fitting for common cases, getting power users banned from various services, various oddball binaries flagged as malicious, etc.

Like most ills today, it's a not-caring-about-externalities problem. If there were real repercussions for rampant false positives, these would be fixed yesterday.

The thing is, these probably aren't rampant. I doubt more than 0.01% of all Windows machines have a Go or Nim binary on them.

False positives doen't just affect Go or Nim binaries, they affect anything that doesn't look exacty like the bloated shit MSVC spits out. It would affect a lot more real programs if their creators hadn't wasted time (and sometimes made their programs worse) to work around bs black box detections.

Assuming technical mistakes reflect intentional policy is kind of conspiratorial.

Far more likely that some ML algorithm trained on malware found the same patterns in legit software, all without any particular knowledge of source language.

anti-virus software is the most dangerous malware that exists, it extracts money from you while slowing down your computer and generally making your life hell for no next to no benefit whatsoever

the amount of productivity lost to useless anti-virus software is incalculable

That's why I don't code on Windows and I don't work for bureaucratic companies where the IT department isn't flexible enough to understand how compilers work and how antivirus software can go wrong.

I had this with a VSTO MSI package I was developing a few years back. Had to submit samples to Microsoft who whitelisted it fairly quickly. This was an EV signed package.

Only components packaged were Microsoft provided!

I don't actively develop in C/C++, but a few year back when I had to use them for a few university assignments I do remember them triggering most AV software.

Don't know if it got better nowadays.

Basically, any binary you compile for Windows needs a special exemption in order not to be flagged by antivirus -- even Defender, which just quietly deleted files I've compiled. You need to contact the antivirus vendors in order to get your software on their allowlist.

Sorry, but it's just the way of the world now.

I wrote an antivirus program that identifies Windows as a virus (simmer down ya'll, I jest)

First question for clarification would be: is it the "SmartScreen popup", or is it an actual malware warning from Windows Defender?

The SmartScreen popup happens for all native executables downloaded from the internet, even when they are code signed with a 'regular' code signing certificate, it doesn't matter in which language those executables had been coded in. Only way around that popup reliably is to buy an expensive "EV certificate" (at least as far as I know) [0].

As far as I understand, SmartScreen assigns an intransparent "reputation score" to executable downloads. Popular downloads have a higher reputation score than propgrams with low download numbers. And programs signed with an "EV Certificate" have a higher reputation score then an unsigned program, or a program with a regular code signing certificate.

TL;DR: if you want to distribute software on Windows outside the Microsoft Store, you need to get an expensive EV code signing certificate.

[0] https://www.digicert.com/support/resources/faq/public-trust-...

I am wondering how long it takes for enterprises to give up on antivirus scam.

Runtime related, maybe.

Nim doesn't really have a runtime though, but there are probably some similarities between all programs written in Nim simply because it's machine generated. And feed the compiler one or two pieces of malware in Nim without any other Nim projects and you quickly end up reporting everything as Nim. Same goes for Go I presume, even though it does have a runtime.

> Nim doesn't really have a runtime though

I don't know much about Nim, but its website claims that it has two possible runtimes[1]. What they dub the "old runtime" and the "new runtime". What's the source of discrepancy here?

[1] https://nim-lang.github.io/Nim/intern.html#runtimes

Unlikely. It's just that some people use these languages for creating malfware and the heuristic scanner grab unto all executables, or the signatures are generated without much care. It's a common problem of smaller languages, e.g. Purebasic executables are frequently flagged as malware.

Microsoft Windows is a malware in the first place. Replaced it with Linux since 1996, never had any problems with 'viruses' since then.

My parents still buys antiviruses for Windows, I told them to switch to Ubuntu long ago.

The online consensus seems to be that Windows Defender (M$'s) is likely the best AV for windows. Perhaps you could tell them to get malwarebytes if they feel the need for one.

IME, Windows Defender does not care about false positives any more than the other vendors.

I think the parent was just trying to save OP's parents some money.

> My parents still buys antiviruses for Windows

That was my intention.

> My parents still buys antiviruses for Windows, I told them to switch to Ubuntu long ago.

If I may offer some advice, don't tell elderly people to change anything, especially about things they're not familiar with, like computers are for many of them. The more people grow old, the more they need familiarity with things. During the years, also thanks to the transition to become a grey beard myself, I've learned the lesson and adopted a different approach, both for relatives and customers: I offer to solve problems at minimum effort, that is, no more viruses, lost data due to OS or software crashes, licenses and their expiration, planned obsolescence and subsequent need to buy new hardware, etc. It goes like "I'm giving you something much better with all your data where you expect them to be; you use it for a while, then after some time if you don't feel comfortable I'll revert it back exactly like before, for free". The "free" part of course is needed outside of family and friends. It is important to keep technical data for ourselves because every term they don't understand would reinforce the perception that Linux can't be used by non technical people and they would fear it long before even having seen it in action. If they ask "what's Linux?" the answer should be like "something like Windows but less problematic" and nothing more. I've started to experience success stories in migrating Windows users to Linux the day I've stopped expecting they could understand what is a compiler, a kernel or the GNU philosophy.

I'm not unsympathetic to your approach, but I have also had users who went from "What is linux?" to recompiling kernels in a couple weeks with no guidance. Sometimes giving users a bit of rope does lead to good outcomes.

In fact today linux looks more windows than windows itself.

> don't tell elderly people to change anything, especially about things they're not familiar with, like computers are for many of them.

Where does this belief come from? Sure it will be challenging for them to get up to speed in a new environment but i don't think there is any rule against learning new things at that age. I would argue that new and different can help improve their mind. Is there any recent science that has provided insight into this?

You're right of course, I was referring mostly to people who aren't familiar with computers. Not that they can't learn new things, but it becomes more difficult with age, and really difficult if one doesn't grok computers already. I might take for example my family, literally filled with people with multiple university degrees, but all the older ones struggled when it came to use computers or learn technical things, while the younger ones like me, my brother and cousins never had problems with that.

My mom gets nervous as soon as there is an unexpected window on the screen. Don't understimate how confusing computers can be to those who did not grow up with them even if they regularly (have to) use them now. Computers are incredibly complex and if you have not developed an intuition for them then you really can't know if something being different means that you messed up or if it is just a normal change. This doesn't just apply to old people (see e.g. people used to Windows tryng Linux or vice versa, people used to GUIs being afraid of the command line) but IME they do seem to be more prone to it.

> I would argue that new and different can help improve their mind.

If it is something they want to learn, probably yes. If it is something forced upon them while they are trying to do something completely different, it can just as well make them even less receptive to learning new technology.

Furthermore I'm kind of convinced even if desktop Linux was a large enough market to be a common malware target for threat actors to bother with, it'd just end up like my grandparent's Mac after about a decade of use - Somehow, still filled with malware after a long while of false assurance that it could never happen.

Unfortunately, Linux will never gain any meaningful market share in the desktop market. Every Linux distro is hostile to their users in some way. I am saying this as a person who actively dislikes windows. Over the years I have tried many Linux distro and none of them is good enough. 1. The Ubuntu fails to wake after sleep (none of the online solution worked for me) 2. I installed openSUSE, but I tried to browse their forums for an issue, I learned that their forum is blocked in my country. Went back to Ubuntu in a few hours. 3. Fedora was very good for a time, wine worked without any tinkering, but the latest update to 37 made my system very slow. Flatpak was not working. It also had issues working with Nvidia drivers. 4. Even tried Arch Linux (you can guess, how that went).

On the other hand, Microsoft is doing everything to appease their users. The Excel software have a bug to maintain backward compatibility. I won't recommend any Windows users to switch to Linux.

Linux desktop users specifically don't have to worry about malware or ransomware until it gets significant usage. Just like people used to say Macs don't get viruses until enough people used them.

Last time I checked (could be very out of date) Linux doesn't have any way to enforce code signing requirements, even in the kernel.

Once again, the hackernews crowd shows their embarrassing lack of security understanding. Every time security stuff comes up, the comments are just cringe. "Durrr fuck M$." Eesh.

By posting here, you're part of that crowd. Maybe you could educate said crowd with a constructive comment about your more nuanced understanding of security.

Sure, RTFA.

To get out ahead of it for people who didn't read: this is about certain third-party antivirus programs, not Windows itself

> I do not think we were able to ever get in contact with anti malware software

I've found it very easy to do so. This statement seems like you didn't use the phone or the keyboard.

We ship Microsoft-signed Go binaries on Windows (via Windows Update) and have never, to date, had any issues with false positives. This smells like clickbait for someone unfamiliar with Windows application release and delivery.

Have you read the linked page? It clearly shows many people have been affected.

> We ship Microsoft-signed Go binaries

Cool. So we just all need to politely ask Microsoft to sign our binaries. What a bright future where Microsoft have the power to decide who lives and who dies.

I know that you'll answer that Apple also does it. Well, it's also an issue.

Who needs courts and laws when you have good corporations :)

Idk how Windows does it, but under macOS, you can change a setting and it'll let you run any binary, but you have to approve it before running it the first time. It's not based on malware detection.

It’s the same in Windows. Well, mostly. You have to click 2 buttons to allow it.

This thread is about AV software, sadly the horrible headline ("on Windows") makes everyone who stopped with the headline comment about unrelated things.

That's what consenting adults do in lieu of 'bcdedit /set testsigning on' via an admin prompt. Alternately, one can call off the antivirus dogs and get on with it.

> Microsoft-signed Go binaries on Windows (via Windows Update)

There is your answer.

It doesn't matter if it's signed or not. It's the AV heuristics that trip on the way the new executables from these languages are build. I have had The AV trigger even on simple Hello world programs while developing. THere is no "sign" option while developing.

We ship Microsoft-signed Win32 binaries via PyPI, and I regularly have to go and deal with new releases being reported as malware. This kind of thing is why release pipelines normally do an automatic submission to a scanning service that checks it across all major anti-malware vendors.

Granted, this is a debugger, which among other things contains code to inject threads into running processes - which, of course, trips any decent heuristic scanner. But there are many broadly legitimate patterns that are also useful to malware and so get falsely reported as such, e.g. https://github.com/nim-lang/Nim/pull/19767

Reply on news.ycombinator.com