Hacker News Reader

Comment by ilaksh | Hacker News Reader

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.

View on HN

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.

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).

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....)

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)

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.

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.

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.

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 ...".

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.

Reply on news.ycombinator.com