Sign wacs.exe using a trusted certificate #1923
Comments
|
My opinion about code signing certificates is that it's largely a money grab, just like server authentication certificates used to be (e.g. the type that Let's Encrypt have already disrupted by offering them for free). I've looked into buying one but besides the cost I didn't like the amount of personal information that they wanted to get and the manual renewal process. The cryptographic strenght of a self-signed certificate is the same as that of a trusted one and realistically they give the "trusted" status to anyone that pays them, so it really doesn't mean much at all. I think you can work around this by added the self-signed certificate to your "Trusted Publishers" store in Windows, or wait until someone starts offering code signing certificates through the ACME protocol. I'd gladly implement something like that in the build process. |
|
I hear you 👍 I just wanted to point out that using a combination of self-signed software on a platform scanning aggressively for malware can lead to unexpected behavior. Though this is not your responsibility, I strongly recommend adding a warning to the documentation. Perhaps mentioning the possible workarounds:
|
|
@WouterTinus I just discovered WIN-ACME. I want to second the motion that you should sign your EXE files. Why? Because...how do I know this is not an elaborate scheme to get me to run an EXE file with Administrator privileges on my server? |
|
If you are so concerned about malicious intent, you can definitely build the project yourself. Though unless you audit all the code you're not really protecting yourself. I'm with Wouter on this. |
|
My motivation for my comment is to help you improve WIN-ACME. Context: = = = = = = = = = = = = = = = = = Microsoft Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk. App: wacs.exe [Run anyway] [Don't run] Suggesting I should just "build it myself" also means I would have to examine the source code and look for "bad" behavior (The Halting Problem). Not exactly a solution for someone looking for a tool to save them effort in creating/installing SSL certificates, eh? ;-) My brief bio: I wrote my first code in 1976, did user support for 1,400+ hours 1978-1982 as an undergraduate student, 14+ years at Microsoft as a software engineer/leader on Windows95, IE, MS-DOS 6.x, OS/2, Java VM, ...). The code I built was used by hundreds of millions of people in the 20th century, and some of my code is still running in +1.7B Windows installations today. Just my two cents. Trying to be helpful I am! |
|
I surely agree with the fact that it's scary for admins and that's why I haven't closed this issue, despite my negative attitude towards for-profit code signing certificates. Us getting a cheap/simple certificate just to get rid of the warning would be a UX improvement, but hardly a security improvement. Assuming you trust that the source code is free of malware (perhaps you even scan through it), you'd still have to verify the whole build, packaging and publishing process (e.g. do we actually build the code that is in the repo and then do we actually publish those builds unmodified. And who are "we" anyway? I'm open for suggestions or best practises employed by similar small scale projects like this one, or better yet some way to use ACME to get code signing certificates automatically. (Whoever came up with "certificate usage restrictions" anyway, that also seems like a money grab.) |
|
@WouterTinus Thank you for these insights. I sent you a connection request on LinkedIn so we can find a time to brainstorm about this issue. |
|
Regarding "Certificate usage restrictions" they generally reflect how what the CA is willing to attest to validation for. So for domain validated stuff you just proved you control the domain, for code signing they generally go down the entity validation path (you are who you say you are, e.g. Company X Ltd). The benefit we found with Certify The Web was just that you could pass windows SmartScreen. Note also that Certbot have only recently started to sign their windows exe (their a latest 64-bit one, no the one they actually link to in their docs). There's often rumblings of the code signing thing changing but really Microsoft could do it overnight as they already do the code signing part for windows store apps, likewise apple do it for iOS, macOS etc. It's silly that the (basically Microsoft only) certs are farmed out to CAs who are often running 10-15yrs old cert acquisition processes for code signing (e.g. you need to use a specific weird version of Firefox . So, there is a benefit but it's quite minor and MS could fix the problem if they wanted to. |
|
An SSL certificate is used to establish a secure communication channel (HTTPS) between a web browser and a server. VERY UNLIKELY that the web server can damage the client/web browser. OF COURSE, if the human being typing at the web browser sends important information -- credit card credentials, Social Security Number, Mother's Maiden Name, etc. -- to a server that is malicious, that is a bad idea. The stakes/risks for running a program (EXE) on a Windows machine are MUCH HIGHER. If you run an EXE with Administrator privilege on Windows, it can wreck havoc -- harvest the entire hard disk, install a keystroke monitor, and more. So it is important that it be MUCH HARDER to sign an EXE file. You want the EXE creator to have a lot of SKIN IN THE GAME, so that it is very unlikely she is a BAD ACTOR. I don't see how this is a "minor" problem that Microsoft could "easily" fix. |
|
@BenSlivka my point is that we are signing exe's in order to specifically comply with Window OS trust mechanism (Authenticode), but Microsoft already provides a trusted publishing workflow for their app store, complete with signing. With Apple you get the same if you publish an app via their store (they are the CA) and with Microsoft you again get the same if you package an app for distribution through their store. Microsoft could leverage their existing app store certification process to allow any publisher to get a signed EXE without possessing their own individually acquired publishing cert from a CA outside of the Microsoft ecosystem. Proving your publisher identity to Apple and Microsoft involves the same process as when proving your organisation identity to a CA (like Comodo/Sectigo), so the end result is the same. Just my opinion, derived from having jumped through a thousand hoops to publish many apps on every major operating system (though not yet Linux, that's next). My company already signs it's EXEs, but I also understand the obstacles for those who don't, not least being the regular cost. |
|
@webprofusion-chrisc Thank you for sharing these insights. Pardon my ignorance, what kind of checking/validation of applications does Microsoft perform before signing them for their app store? My understanding is that both Apple and Google do quite a bit of "validation" before approving mobile apps for their app stores. For your company: how much time and expense is it for you to sign an individual EXE? Is there some fixed costs (e.g., registration/validation of your company) plus a per-EXE cost? Thank you! |
Yes, but shouldn't it be up to the user (and their admins) to decide how much validation is required for them? E.g. if I start an unknown program, the OS could now reports something like:
But why should I trust that more than other similar messages like:
Which one would/should you trust more? The former will always be more difficult/expensive, so the idea is that it would be less popular with criminals doing quick cash grabs. But on the other hand the extra trust given to the EV version could make it worth the up-front investment to be able to scam more people. Browsers have long all but completely abandoned the distinction for that reason. I would personally also rather whitelist certain companies/authors on my systems than give blanket trust to whoever buys (or steals) a code signing certificate from anywhere. Perhaps desktop admins are not ready for this😄. |
|
@WouterTinus You ask excellent questions. I expect most (large) IT shops have very specific policies about what EXEs can be run on what machines. In IE 1.0 (released in 1995) we decided to mark *.DOC, *.XLS, *.PPT files as "possibly dangerous". Why? Because those Microsoft Office document formats could contain "Auto-Open" macros (VB) that ran when you opened them. So we worried that could be an attack vector. The general manager of the Word group was pissed at me at the time, and when the (inevitable) Word macro virus appeared, he actually accused me of writing it. It pointed out it was much better that I had merely predicted it. I agree that the current situation for small software developers is that there is no easy/obvious/convenient/inexpensive way to prove your Windows EXE is benign. Because...The Halting Problem. |
|
The Apple/Android app stores have a simpler problem, because by default each app runs in a "sandbox", so isn't able to touch the data of other applications. And shared areas (like photos/videos, microphone, phone dialing, etc.) require explicit granting of permission. |
|
@WouterTinus yes I agree code signing and authentication of publishers etc is not optimised for reality, it's just an existing (windows) feature that we have to work with (or not) and just part of the "swiss-cheese" problem of covering up one potential security hole. @BenSlivka regarding signing and validation, app store apps do get API usage scans and in the case of windows they get a cursory test by a real person at Microsoft (likewise Apple). Android is a little more relaxed. No there's not really a per exe cost, it's typically a build step that you automate, there is however (for standard code signing) a regular annual cost to maintain your code signing certificate with the CA, plus the administrative work to apply for that, get the new cert, update build processes etc. |
|
@WouterTinus THANK YOU for win-acme. I've been running Windows Server (starting with SBS 4.5) since 1999. When Chrome started to fuss about http, I went through the rigmarole (and expense) of SSL certs at GoDaddy and then trying to install them on IIS. Very painful. My slivka.com cert just expired, and I used win-acme, and in 5 minutes I had a new cert and my website is fine. SO MUCH EASIER! |
|
@WouterTinus Have you consider adding the IIS "URL Re-Write" to WIN-ACME? This causes all http: requests to automatically be changed into https: requests. |
Having a signed EXE is literally 0 guarantee that said EXE doesn't contain any malicious code. As a matter of fact, there's a lot of malware being distributed via the ads shown in google search results right now, all of which could've been signed just as easily. The only way to ever be 100% sure a file does not contain anything malicious is by checking the source code yourself, and compiling it yourself. But you can be pretty much 99,9% sure by just checking where you download a file from, and verifiying the source's trustworthyness. |
|
Sigh.
I was at Microsoft when we created signed EXEs.
Merci,
--Ben
On Feb 5, 2023 8:37 AM, Jorin Vermeulen ***@***.***> wrote:
how do I know this is not an elaborate scheme to get me to run an EXE file with Administrator privileges on my server?
Having a signed EXE is literally 0 guarantee that said EXE doesn't contain any malicious code. As a matter of fact, there's a lot of malware being distributed via the ads shown in google search results right now.
The only way to ever be 100% sure a file does not contain anything malicious is by checking the source code yourself, and compiling it yourself. But you can be pretty much 99,9% sure by just checking where you download a file from, and verifiying the source's trustworthyness.
—
Reply to this email directly, view it on GitHub<#1923 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABZEWNZPVKJE4HCJWMOVQCLWV7XNFANCNFSM5EDLGW3A>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
I really do not see how that is relevant in any way. Let's also keep things relevant to this issue. |
|
My apologies.
Peace,
--Ben
On Feb 5, 2023 8:48 AM, Jorin Vermeulen ***@***.***> wrote:
I was at Microsoft when we created signed EXEs
I really do not see how that is relevant in any way. Let's also keep things relevant to this issue.
—
Reply to this email directly, view it on GitHub<#1923 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABZEWN4SLOOVSVRXX7WVLOTWV7YYZANCNFSM5EDLGW3A>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
The wacs.exe file is signed as win.acme.simple@gmail.com, but the certificate path is not valid. I guess the certificate is not from a trusted CA (self-generated).
Until recently this did not cause an issue on our server, but today I noticed that Acronis Cyber Protect 15 had blocked and reverted some changes made by wacs.exe to files in ProgramData. Acronis Cyber Protect 15 is used by many for backup and protection against malware.
The issue is not immediately related to wacs.exe as such, since Acronis can be set up to whitelist the wacs.exe process. However, the process would not have been blocked in the first place if the file had been properly signed (according to Acronis).
wacs.exe is after all used to generate valid trusted certificates, so wouldn't it make sense to also sign the file using a certificate from a trusted CA?
We at least always sign our own application files using a certificate from a trusted CA (e.g. Comodo, which is what we use. Got it for $69 per year).
Perhaps I should add that I could of course also just remove the untrusted certificate and sign the file using our Comodo certificate, but it shouldn't be like that and other users might not have that option.
The text was updated successfully, but these errors were encountered: