41–50 of 138 posts
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.
Then you don't understand why people use them.
I feel like the headline is a bit click-baity but I don't want to jump to conclusions. > 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 signatur…
I'm still trying to figure it out too: > I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash? Yeah, I think that's the problem they're describing. It sounds like the Mac setup will require binaries -- like the Electron runtime itself -- to be codesigned, but if the first thing your codesigned binary does is to read an unprotected JS file off disk and execute it, there's…
Good point, but if the attacker has filesystem access you're already hosed. I suppose there could be some other risk where the ASAR could be modified without full FS access? But I'd want to know what that attack is, if that's the case.
> 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.
This appears to be the issue that is referenced in the article about why they don't sign currently: https://github.com/electron/electron-packager/issues/656#iss...
Earlier quoted context omitted.
I'm still trying to figure it out too: > I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash? Yeah, I think that's the problem they're describing. It sounds like the Mac setup will require binaries -- like the Electron runtime itself -- to be codesigned, but if the first thing your codesigned binary does is to read an unprotected JS file off disk and execute it, there's…
> Not just updates that you initiate yourself, though -- I think the idea is that any other app on the system could backdoor the JS in the ASAR at any time. That's pretty hard to defend against. Good point, but if the attacker has filesystem access you're already hosed. I suppose there could be some other risk where the ASAR could be modified without full FS access? But I'd want to know what that attack is, if that's…
I think that's not supposed to be true in modern (e.g. latest macOS) threat models. App Y isn't permitted to just replace App X unannounced, and on both Mac and Win there's a large codesigning infrastructure in place to provide that protection.
We've updated the link from https://arstechnica.com/information-technology/2019/08/skype... , which points to this.
Here is the Google Cache link https://webcache.googleusercontent.com/search?q=cache:xeIOGz...
1) We should absolutely work towards allowing developers to sign their JavaScript.
2) Re-packaging apps and including some menacing component as a threat vector isn't really all that unique. We should ensure that you can sign "the whole" app, but once we've done that, an attacker could still take the whole thing, modify or add code, and repackage. We sadly know that getting Windows SmartScreen and macOS to accept a code signature doesn't necessarily require exposing your identity and I'd _suggest_ that most people don't _actually_ check who've signed their code.
3) If you ship your app as a setup bundle (say, an AppSetup.exe, an App.dmg, or rpm/deb files), you should code-sign the whole thing, which completely sidesteps this issue. The same is true if you use the Mac App Store, Windows Store, or Snapcraft Store.
> attackers could backdoor applications and then redistribute them
Most distribution mechanisms however ship a single signed bundle, containing & thereby signing the entire application, including resources like ASARs. Any that don't sign the application are of course vulnerable to all sorts of trivial attacks (replace the whole binary with anything you like).
To make this a danger from a distribution POV, it seems you would need the application to be partly signed; i.e. the executable but not the included resources. Where does that happen?
For macOS for example, all resources (including ASAR files) are signed, and macOS makes it intentionally difficult to install anything that isn't signed.
Similarly for Windows you'll see large warnings if you open an unsigned application; Electron apps are almost always distributed as a single signed installer exe file, including the ASAR file.
On Linux it depends wildly, but most of the time either the entire package (e.g. a deb from the official repos) is signed, or nothing is signed and you're vulnerable regardless.
What am I missing?
(I'm not addressing the risk of altering an already-installed application - that's a separate attack also mentioned, but requires local access to rewrite files on the target machine, at which stage there's many other options)
EDIT: URL has now been updated, here I'm discussing points from https://arstechnica.com/information-technology/2019/08/skype.... The post now referenced doesn't mention redistribution, and I suspect that in fact Ars is wrong, and allowing signed redistribution of subverted versions isn't a real vulnerability here. I'd love to hear if I'm wrong though!
Earlier quoted context omitted.
It makes cross-platform desktop development much easier. VSCode, Discord, and (the new) Slack are written in Electron, and those absolutely excel, even at the cost of a bit extra memory usage. There's a circlejerk of Electron hate, but there's a reason it's so popular, the ease of development outweighs its weighty memory drawbacks for many companies and individuals. Edit: Not to mention that it uses Node.js, HTML, CS…
> It makes cross-platform desktop development much easier. For the developer, while the user has to deal with horrid battery and memory consumption. Devs are paid well enough that "easy" shouldn't be a top priority.
Easy is a priority for many OSS projects and companies who want to ship something quick and reliable.
Electron is the new Flash. Change my mind. ¯\_(ツ)_/¯
It makes cross-platform desktop development much easier. VSCode, Discord, and (the new) Slack are written in Electron, and those absolutely excel, even at the cost of a bit extra memory usage. There's a circlejerk of Electron hate, but there's a reason it's so popular, the ease of development outweighs its weighty memory drawbacks for many companies and individuals. Edit: Not to mention that it uses Node.js, HTML, CS…
That is literally how Adobe Air was billed
At 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.
This is actually good advice. Anything you want to keep secret should stay in your mind. Anything else gets progressively risky.
Only other considerations are to have a more basic hash for certain financial websites/insurance companies (cough Allstate) that for some reason think an 11-character max password is still okay in this millenium, and to have a method of "incrementing" the password in case you have a service that forces rotations. The only reason to write the hash down is for financial service access in the case of estate planning - store it securely/safely, of course.
Ever since switching to this, I've found it's even more convenient than a password manager. You get used to running your hash in a very short time, and don't need to have access to an electronic device to recall a password.