Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Basic Electron Framework Exploitation

contextis.com

Post reply on HN
Print view View original

51–60 of 138 posts

Re: Basic Electron Framework Exploitation

#51

Post by withinrafael »

pfraze wrote: post #20

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…

Developers on Windows, in this scenario, can generate a catalog of all files in their app and sign that/verify that at runtime [1], negating the need to rely on upstream to incorporate signature support into the asar file spec. There may be workable equivalents on macOS and Linux.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/in...

But this will all be in vain if the attacker scenario includes unfettered file-system access. (They can modify the app to not perform these checks, for example.)

Re: Basic Electron Framework Exploitation

#52

Post by cjbprime »

felixrieseberg wrote: post #46

Electron co-maintainer here, so I'm a bit biased. 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 g…

I don't think it's correct that 3) sidesteps the issue, if I'm understanding it. Electron App is installed via a codesigned setup bundle. Then Malicious App runs on the machine later and overwrites your ASAR. The OS doesn't complain because the ASAR isn't receiving codesigning protection, and Electron App has been backdoored in a way that the system's use of codesigning suggests wouldn't be possible.

Re: Basic Electron Framework Exploitation

#53

Post by hnbroseph »

cjbprime wrote: post #29
pfraze wrote: post #20

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…

if you have malicious code executing that has the access and opportunity to modify files, a modified electron app is likely just the beginning of your troubles.

Re: Basic Electron Framework Exploitation

#54

Post by packet_nerd »

bsmith0 wrote: post #22
mavdi wrote: post #3

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…

Slack excels? In my experience it's really slow and clunky and consumes way more memory than it should.

As the sysadmin at my company I ban all electron apps unless it's clear they are exceptionally well written and/or there are absolutely no alternatives. VSCode is really good and one of my few exceptions. I strongly suspect it would have been even better if they had developed with a more performant platform, but who knows.

Edit: To expand on my reasoning:

Say an operation on a well built performant application is 5 seconds faster than the electron (or otherwise bloated) version. Say employees do that operation on average 20 times a day. Say I have 2500 employees who work 246 days a year and get payed $25/h on average. The slow version will cost the company $427,083 every year. That's the amount of money I'd be willing to spend per year for the fast version of this hypothetical application.

A company like Slack has hundreds of thousands of users and the poor performance must be costing someone millions. It boggles my mind that with all that money, they still can't find the resources to make a performant application?

And that's the naive calculation, there's also the administrative aspect of installing, upgrading, and supporting the application. (The worse the applications quality, the more time I, who am payed a lot more than $25/h, spend supporting it.) While there are multiple variables here, a development team that prioritizes "easy and fast" development doesn't inspire me with confidence they have also prioritized building a quality product.

Re: Basic Electron Framework Exploitation

#55

Post by some_furry »

felixrieseberg wrote: post #46

Electron co-maintainer here, so I'm a bit biased. 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 g…

> 1) We should absolutely work towards allowing developers to sign their JavaScript.

I've already been working on this for my own projects. It might be something that can be generalized for all Electron projects.

https://github.com/soatok/libvalence

https://github.com/soatok/valence-updateserver

https://github.com/soatok/valence-devtools

This uses Ed25519 signatures and an append-only cryptographic ledger to provide secure code delivery. The only piece it's currently missing is reproducible builds.

For greater context: https://defuse.ca/triangle-of-secure-code-delivery.htm

Re: Basic Electron Framework Exploitation

#57

Post by vanilla_nut »

sixothree wrote: post #34
bsmith0 wrote: post #22

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…

I don't know why people complain about performance. VSCode is my primary experience with Electron and it runs extremely well. It handles large files just as well as Notepad++. edit: Just to be clear I don't suggest notepad++ is best at large files. EditPad is clearly the winner in that category. But I do mean to say VSCode and N++ are on par with each other. Besides, VSCode provides an incredible amount of functional…

VSCode is generally considered to be the canonical example of an Electron app well optimized. They have put a significant amount of work (much moreso than your average company producing an Electron app) into making it very responsive. All you have to do is use Slack or Discord or Atom or Skype and you'll quickly understand why people hate on the performance.

Spotify is a good example of an application that doesn't use Electron (though it uses a similar framework) and still manages to be incredibly slow and bloated. As are most websites. So the problem might not be that Electron is slow... it might just be that the web in general is really slow unless you work extra hard.

Re: Basic Electron Framework Exploitation

#58

Post by xigency »

saagarjha wrote: post #13
thecopy wrote: post #9

Earlier quoted context omitted.

Or the new JAVA

Java actually made an effort to look like the platform it was on, though.

That has never been my impression. Java applications have a Java look.

What has actually impressed me as an easy way to do native looking UIs, albeit simple ones, is PyTK. On Windows, you can even select between the different styles that are internal.

Re: Basic Electron Framework Exploitation

#59

Post by benbristow »

d2mw wrote: post #49
bsmith0 wrote: post #22

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. That is literally how Adobe Air was billed

Except to run Adobe Air applications you needed to install/distribute the proprietary closed-source Adobe Air runtime.

Electron is just web technologies wrapped with a library to call system APIs.

Re: Basic Electron Framework Exploitation

#60

Post by cjbprime »

some_furry wrote: post #55
felixrieseberg wrote: post #46

Electron co-maintainer here, so I'm a bit biased. 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 g…

> 1) We should absolutely work towards allowing developers to sign their JavaScript. I've already been working on this for my own projects. It might be something that can be generalized for all Electron projects. https://github.com/soatok/libvalence https://github.com/soatok/valence-updateserver https://github.com/soatok/valence-devtools This uses Ed25519 signatures and an append-only cryptographic ledger to provide…

I think you need OS codesigning integration for this threat model. Otherwise whatever special app runtime check code you add just gets removed by the malicious overwrite of your app code.
Post reply on HN