Electron-packager: Signing Windows installer doesn't sign every binary

[drjasonharrison]

• [x] I have read the contribution documentation for this project.
• [x] I agree to follow the code of conduct that this project follows, as appropriate.
• [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Please describe your issue:
It appears that electron-packager and electron-wininstaller do not support signing all of the Windows binaries such as ffmpeg.dll, libEGL.dll, and node.dll; AND the resources/*.asar. This means that someone could replace the files in resources/*.asar or the unsigned dll's with malicious code.

Who is looking into this issue?

[malept]

Thanks for filing an issue, but this is not an Electron Packager issue. Packager does not currently handle signing on Windows (or proxy it to another module). The other issue you filed in the electron-winstaller project is a better place for this.

[develar]

Asar file cannot be signed using windows tool. File format doesn't support it simply. Electron should support it, because it is not possible to implement check on application side (since asar files can be changed).

Good news is that on macOS it is possible to fix without Electron team — https://stackoverflow.com/questions/35013006/where-does-codesign-store-the-signature-for-a-signed-text-file-on-osx I will file PR to electron-osx-sign soon (cc @sethlu).

[drjasonharrison]

Yes, sadly Windows went fully for the "sign only the executables" where the definition of "executables" has become increasingly out of date. It sounds like the electron/asar library would need to be extended, or a detached signature for the resource/*.asar files be embedded in the electron-builder output.

And as in my situation, the signing would need to be able to be performed by a third party tool.

I'm some what surprised that this issue hasn't already been raised by any of the other electron application users. I've filed https://github.com/electron/asar/issues/123

[MarshallOfSound]

@develar @malept @drjasonharrison I've done quite a bit of research into code signing ASAR files to protect against source code injection in Electron applications and I've got a few things to say here.

1. Unless the OS is doing the verification there is always a way around internal signiture verification, it might be a lot harder but it will always be possible to bypass an application that self-validates for the obvious reason that you could modify the bit of the program that does the self-validation. Just look at game DRM where companies spend years trying to make their game uncrackable, it always gets cracked eventually 😆

2. macOS doesn't verify static assets at runtime, you can codesign any files you want in the app but only what apple considers "runtime code" will be validated, this means the Electron binary and the Electron Helper binaries will be validated but static assets like .asar files and other such files will not be validated

3. Windows doesn't do any signature validation on anything that isn't an .exe or .dll and even then it will sometimes still launch invalid or unsigned files 👏

4. This is the big one for me, in order to actually exploit this (changing an ASAR file) the malicious program / attacker needs physical access / to be already running in a privileged state on your users machine at which point they can do whatever they want anyway, including replacing your application completely with a fake one with a valid signature that looks the same 😆 Once the user has lost control of their own machine there is little we can do as developers to protect them.

All this said I would love if someone could prove me wrong and come up with a foolproof way to sign and validate static resources cross-platform (or even just one platform would be impressive) but I'm pretty sure it's not possible and I don't believe the teams stance on source code protection has changed.

[develar]

@MarshallOfSound thanks for summary. (To be clear, here we are talking only about code validation, not source code protection or app licensing).

1. But app is cracked using cracked license servers / license generation. Not using simple hex editing of exe file. Or I am wrong? Anyway — codesign on Windows doesn't work. Because not enabled by default (blocking unsigned code), easy way to bypass UAC (e.g. NSA exploit).

2. 1. Yes — https://stackoverflow.com/a/4716079/1910191 I doubt that Electron or node check DLL signature.

3. how app can be replaced? You need to have private key to sign. Sha2 not yet broken to produce the same hash. Access — due to easy auto update, nsis/Squirrel both install app by default to user directory.

[MarshallOfSound]

@develar Yeah, validating code has the same limitations as mentioned before though 😞

1. Cracking license servers is only useful for getting the game for free, also talking about modding the content of the game which is more on-parr with this topic. The best metaphor I saw for describing this went something like this

Imagine you have a box and you want to keep it's content safe, but you have to store the key to the box with the box itself or at least within easy reach of the box. You can see how you could hide the key, put decoy keys all over the place. But eventually someone would find the correct key and the whole charade would be pointless

1. Yeah, but that's still self-validation 😄 Change the core code for the application and there goes the validation because windows doesn't enforce validation of signatures at an OS level it's basically a catch-22.

2. Well I mean on macOS replacing the app is as easy as executing a bit of bash

rm -rf /Application/MyApp.app
mv /path/to/fake/app.app /Applcations/MyApp.app

It's a technique I've seen used before, if the app has a similar UI (possibly even a slightly modified version of the original app) and the same icon / name the user won't notice a thing and as long as the new app is signed with a valid cert, macOS won't complain either 😢

[drjasonharrison]

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

[drjasonharrison]

@MarshallOfSound this isn't a source code protection issue. It's a cover-my-ass issue.

Release checklist:

• [ ] installer is signed with corporate derived certificate
• [ ] post-installation, all executable components are signed with corporate derived certificate
• [ ] etc

[develar]

@drjasonharrison Let's discuss in the https://github.com/electron/asar/issues/123