It is amazing to see how large, fat, over-engineered frameworks are taking over the internet. Not only it is easy to backdoor but usually they consume an enormous amount of memory and CPU. Not sure how we ended up here.
Basic Electron Framework Exploitation
11–20 of 138 posts
Re: Basic Electron Framework Exploitation
#12> The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed Resources on macOS get signed as part of the application bundle. I wonder why this isn't possible for Electron apps as well.
https://github.com/electron/electron-packager/issues/656#iss...
Re: Basic Electron Framework Exploitation
#13Re: Basic Electron Framework Exploitation
#14At this point in time, it's reasonably healthy to assume that everything has backdoors. The only place where information can be kept safe and hidden is deep within our minds. Any method used to share said information with another human being is subject to surveillance and backdoors. Only share what you don't mind being read by the state and it's friends.
For some reason, the key to my mind’s backdoor is beer.
Re: Basic Electron Framework Exploitation
#15Electron is the new Flash. Change my mind. ¯\_(ツ)_/¯
Re: Basic Electron Framework Exploitation
#16At this point in time, it's reasonably healthy to assume that everything has backdoors. The only place where information can be kept safe and hidden is deep within our minds. Any method used to share said information with another human being is subject to surveillance and backdoors. Only share what you don't mind being read by the state and it's friends.
Re: Basic Electron Framework Exploitation
#17>Tsakalidis said that in order to make modifications to Electron apps, local access is needed, so remote attacks to modify Electron apps aren't (currently) a threat. But attackers could backdoor applications and then redistribute them, and the modified applications would be unlikely to trigger warnings—since their digital signature is not modified.
Re: Basic Electron Framework Exploitation
#18It is amazing to see how large, fat, over-engineered frameworks are taking over the internet. Not only it is easy to backdoor but usually they consume an enormous amount of memory and CPU. Not sure how we ended up here.
Cross-platform guis are hard or ugly and html+css came to save the day
Re: Basic Electron Framework Exploitation
#19It is amazing to see how large, fat, over-engineered frameworks are taking over the internet. Not only it is easy to backdoor but usually they consume an enormous amount of memory and CPU. Not sure how we ended up here.
The fact that billion dollar companies insist on continuing to take the shortcut approach when they have the resources available to "be better" is not the fault of framework developers who originally innovated to fill the demand
Re: Basic Electron Framework Exploitation
#20> Tsakalidis said that in order to make modifications to Electron apps, local access is needed, so remote attacks to modify Electron apps aren't (currently) a threat. But attackers could backdoor applications and then redistribute them, and the modified applications would be unlikely to trigger warnings—since their digital signature is not modified.
So the issue is that Electron app distributions dont include a signed integrity check so there's no way for end-users to detect if they got a modified version. I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash, or maybe I'm wrong entirely.
I assume the a solution would store the signing pubkey on initial install and then check updates against that. The only way the signing key could be checked other than trust-on-first-install would be through some kind of registry, which is what I assume the Windows and Mac stores are geared toward. Am I correct on all this?
EDIT: Either way, it seems like the solution is to only use the projects' official distribution channels. Signed integrity checks would be useful but probably not change the situation that dramatically. Is that accurate?