electron / fuses

MIT License
42 stars 16 forks source link

Fuses property is not working as expected in Windows #49

Closed kvswamy86 closed 2 months ago

kvswamy86 commented 2 months ago

const { FusesPlugin } = require('@electron-forge/plugin-fuses'); const { FuseV1Options, FuseVersion } = require('@electron/fuses'); const forgeConfigMac = require('./forge-config-mac'); const forgeConfigWin = require('./forge-config-win'); const { logMessage } = require('./util');

if (process.platform === 'darwin') { logMessage('Loading macOS Forge config'); logMessage(JSON.stringify(forgeConfigMac, null, 2));

forgeConfigMac.plugins = [ new FusesPlugin({ version: FuseVersion.V1,

}), ];

module.exports = forgeConfigMac; } else if (process.platform === 'win32') { logMessage('Loading Windows Forge config'); logMessage(JSON.stringify(forgeConfigWin, null, 2));

forgeConfigWin.plugins = [ new FusesPlugin({ version: FuseVersion.V1,

}), ];

module.exports = forgeConfigWin; }

As shown in the above sample code we are generating the packaging using Electro Forge. After this App launch is successful also we can read the properties through the command line like npx @electron/fuses read --app app-name

Now we are trying to modify the same properties by using the CLI

npx @electron/fuses write --app "appname.exe" EnableEmbeddedAsarIntegrityValidation=off

The expected behavior is the app launch should fail as we rewrite the properties through the command line but in Windows, the app Launch is successful after writing the properties whereas in Mac the app Launch fails if we rewrite the properties through the command line

The issue exists only in Windows

MarshallOfSound commented 2 months ago

The expected behavior is the app launch should fail as we rewrite the properties through the command line but in Windows, the app Launch is successful after writing the properties whereas in Mac the app Launch fails if we rewrite the properties through the command line

This is funamentally how therse two operating systems work. On macOS modifying the binary after it has been code signed results in a hard crash / loss of code signing integrity at a minimum and the OS itself will reject the app.

On Windows this is not default behavior, it requires policy level enablement of AppLocker with rules that protect against unsigned / modified applications.

The goal of Electron fuses is to extend OS level protections to other resources, so on windows if AppLocker is not configured there is no protection to extend.

kvswamy86 commented 2 months ago

Thanks for the info @MarshallOfSound Without signing also, Mac is not launch the app if we modify any of the properties. Then what could be the issue in Windows

MarshallOfSound commented 2 months ago

All apps on macOS are signed, even if they don't have a proper identity. Unsigned apps have an "adhoc" signature which can still be invalidated by modifying the binary.

If you check the code of this module you'll see for unsigned apps we reset the adhoc signature when appropriate.

My first comment is still correct, the windows os does not have anywhere close to the same level of protection as macOS

kvswamy86 commented 2 months ago

Sorry I missed your point for mac , thanks for your clarification @MarshallOfSound

Regarding the Windows issue, I was wondering if it's possible to calculate the checksum of an executable (EXE) file. If any property value of the EXE is modified through the command prompt, the checksum would change. Considering this, could you add a property similar to EnableEmbeddedAsarIntegrityValidation but for EXE validation? For example, a property like EnableEmbeddedExecutableIntegrityValidation would be helpful.

We're currently implementing this on our side, but having a built-in property for this would be greatly beneficial.

MarshallOfSound commented 2 months ago

What you describe is not possible, self validation is trivially bypassable. Validation that is extended from the OS is the only valid answer (hence why this works well on macOS and on windows depends on applocker)