asar
asar copied to clipboard
Code Signing of ASAR files, especially for Windows operating system
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.
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.
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.
What are your gatekeeper settings? System Preferences > Security & Privacy > Allow apps downloaded from
@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.
https://github.com/electron/electron/pull/9648
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.
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.
Is it possible to revisit this topic? I assume things have changed since 2017 regarding OS security
@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?
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.
Is there an update on this topic?