Code Signing of ASAR files, especially for Windows operating system

[drjasonharrison]

With the increasing usage of Electron-builder to create Windows app, I believe that the lack of support for signing ASAR files, and the confirmation that the asar files are signed, will lead to a malicious modification of files in a users AppData\Local*\app*\resources

Easy targets include failure of the developer to use electron-winstaller to sign all of the .dlls and Update.exe. For example, at some companies third party code signing utilities and signing servers are used instead of distributing certificates to build servers.

As of this point electron does not check that asar files are signed, and electron-winstaller does not (can not) sign the files, even with a detached signature, and have this signature verified at runtime. SInce the asar (and "raw" javascript) can include shell commands that might ask for elevated permissions, especially at installation time, or use a zero-day exploit, electron apps are all potential targets for malicious code.

[develar]

Discussion started here — https://github.com/electron-userland/electron-packager/issues/656#issuecomment-304502144

I will continue here (since issue can be fixed only on electron side, not in userland).

I propose to validate asar file. Using sha hash (stored in the executable file / Info.plist, so, will be not possible to modify without broke code signature).

Regardless of how is Windows bad and unsecure, electron should not allow to bypass code signing so easy.

@MarshallOfSound @kevinsawicki Will electron team accept such PR? I will have several free days soon and I want to experiment.

[develar]

Another option is to put all static assets in a native library file. .asar becomes .dll or .so/.a

It is not an option because DLL signature is not checked. I am going to experiment with windows resources to store asar files or using checksum to verify external asar file.

As @MarshallOfSound said, even on macOS code signing of non-executable files means nothing. Nothing. App bundle will not pass static validation, but... dynamic validation (performed on run) will be passed. Tested on non-Electron Java application, where ALL jars are signed, but regardless of that, jar can be modified and app can be still runned without any warning. So, code signing for Electron apps currently does nothing. Absolutely nothing. You can simply download any verified signed app, replace asar file, and voila.

[drjasonharrison]

What are your gatekeeper settings? System Preferences > Security & Privacy > Allow apps downloaded from

[develar]

@drjasonharrison Since macOS Sierra no UI setting to disable Gatekeeper. The only way to run unsigned app — using explicit Open or disable Gatekeeper using Terminal (sudo). But Gatekeeper doesn't work for electron/java applications.

[develar]

https://github.com/electron/electron/pull/9648

[TJKoury]

I feel like the open source community needs to come up with its own standard for code signing / verification. It's simple enough to create a hash, and verify the hash.

[davej]

I hate to do a +1 type comment but this is potentially a huge vulnerability and negates the reason for signing code in the first place. It seems like it's only a matter of time before Skype/Slack/VSCode gets packaged up with malicious code and flies under the radar of SmartScreen, Gatekeeper and similar.

Sorry that I have nothing substantial/helpful to add but this issue seems to have been forgotten and I think it's worth surfacing it again.

[rajivshah3]

Is it possible to revisit this topic? I assume things have changed since 2017 regarding OS security

[bnxi]

@MarshallOfSound @miniak , I have a suggestion for tamper protection of asar files and other non-PE assets of an electron app on Windows OS. Is there a RFC process for evaluating it or I should just add it to this issue?

[bnxi]

I'm including my suggestion here, hopefully it will be picked up and evaluated:

The suggestion is to leverage windows catalog file (.cat) that is a single signed file containing crypto hashes of multiple other files. The WinVerifyTrust API has built-in support for trivial verification of catalog file digital signature AND integrity of a files included in the catalog. This method could protect multiple files against tampering (load time protection) regardless of their format using a code signing certificate and by signing a single catalog file.

[DM223]

Is there an update on this topic?

[mikehearn]

So here's the deal as of May 2024.

MacOS

Starting from one or two major releases ago, macOS now blocks apps from modifying each other. The prior ability to modify files and have the app start up wasn't really a security vulnerability per se, it was just how the OS worked, because code signing was deliberately only checked when an app was first downloaded using GateKeeper. That's still the case but now apps can't modify other app files unless they have the "full disk access" or "manage apps" permissions. So ASAR integrity or checking by Electron itself is not necessary on this platform.

Windows

Windows is in general quite far behind Apple when it comes to code signing topics. Nonetheless, if you distribute software in the way Microsoft wants you to (using their MSIX format) then app files are all fully signed, including the ASAR file, and the app files are protected from tampering post-install. So once again there is nothing that needs to be done here by Electron.

Now making MSIX files is not particularly easy. The reason I noticed this bug is because my company makes a product (free to use for open source projects) that makes it easy to distribute desktop apps, and it uses MSIX files behind the scenes. So Electron apps distributed with that tool are fully protected with nothing they need to do. Making this work well does involve unfortunately a lot of workarounds for bugs in different versions of Windows so I wouldn't recommend you try to use it without our product. It will appear to work and then you will get error reports from an apparently random set users. We got it working stably after a lot of effort, and the benefits are significant, but it's not pleasant to deal with when using the MS toolchain (whether directly or via forge/builder).

What if you want to use more classical Windows installer tech like NSIS? Well, then indeed data files can be swapped out at will, but Microsoft doesn't "blame" you for this because it's the nature of how classical non-MSIX packaged apps work. There is no expectation that apps verify the integrity of every file loaded themselves. Yes, it means code signing means not much if your main EXE loads arbitrary code and executes it from data files, but MS have a solution and are waiting for devs to adopt it. So ... don't worry about it.

[MarshallOfSound]

Welcome to 2024, we have Asar Integrity now --> https://www.electronjs.org/docs/latest/tutorial/asar-integrity