Earlier quoted context omitted.
name one way in which they're similar (beyond "I don't like either of them")
No. You're supposed to change his mind.
And rhetorical questions won't do that?
Basic Electron Framework Exploitation
61–70 of 138 posts
Re: Basic Electron Framework Exploitation
#62Electron 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.
If you're already running code on the victim's machine, presumably with sudo rights to change `/Applications`, you've already hit the jackpot. Yes, you can change apps, but if you're the victim, that's _probably_ not the biggest issue. It's the rootkit on your machine.
Re: Basic Electron Framework Exploitation
#63Earlier quoted context omitted.
> 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…
> If the attacker has filesystem access you're already hosed. 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.
Also, sandboxing is designed to prevent unfettered filesystem access on macOS, meaning this isn’t part of the threat model if all apps are sandboxed and packaged.
Re: Basic Electron Framework Exploitation
#64Earlier quoted context omitted.
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.
If you're already running code on the victim's machine, presumably with sudo rights to change `/Applications`, you've already hit the jackpot. Yes, you can change apps, but if you're the victim, that's _probably_ not the biggest issue. It's the rootkit on your machine.
This (FS write access == game over) is usually true on Linux, but the Mac and Windows codesigning infrastructures exist to offer some protections and user warnings in this case, and they're what's being defeated by this attack.
Re: Basic Electron Framework Exploitation
#65Earlier 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…
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 wh…
The new Slack app, introduced last month, makes using it feel snappy. It also uses significantly less RAM.
Re: Basic Electron Framework Exploitation
#66Earlier quoted context omitted.
name one way in which they're similar (beyond "I don't like either of them")
No. You're supposed to change his mind.
"here's zero explanation as to why i believe the thing that i believe. change my mind" is the laziest and dumbest form of argument ever.
Birds aren't real, change my mind.
Re: Basic Electron Framework Exploitation
#67This is clickbait nonsense. Unfortunately, because it's so popular to hate on Electron these days, it's going to get a lot of traction on HN and elsewhere. The premise of the blog post is:
> It’s important to note that this technique requires access to the machine, which could either be a shell or physical access to it
I mean... what? I can literally do code injection on (almost) any application I'm running given that I have shell or physical access to the machine. It's like the author never heard of Detours[1] or VTable injection[2]. This is a low-effort clickbaity post that brings nothing to the table to serious security researchers or even hobbyist hackers.
It's a shame, too, because there are a lot of very interesting techniques out there for injection and remote execution, but they are OS-dependent and require a lot of research. Clearly, a more interesting post would have been too much effort for OP and instead we're going to pile on Electron.
PS: ASAR code-signing is not fool-proof, as we can still do in-memory patching, etc. Game hackers have been patching (signed) OpenGL and DirectX drivers for decades. It's a very common technique.
[1] https://www.microsoft.com/en-us/research/project/detours/
Re: Basic Electron Framework Exploitation
#68This is pure FUD. Literally "hacker with her hands on your keyboard can compromise your machine."
Re: Basic Electron Framework Exploitation
#69This article seems a bit clickbait-y considering this means that you'd have to download the application from an untrusted source for this "exploit" to be taken advantage of. The same could be said for most applications if people aren't checking that the hashes match. I feel like this will get a ton of discussion here anyway due to the Electron hate train.
What if you installed it via a trusted source, and then someone swapped the ASAR files without your knowledge? A flash-drive programmed to operate as a keyboard could easily swap in a malicious file simply by plugging it into the victim's computer when they aren't paying attention.
Re: Basic Electron Framework Exploitation
#70Here's the corresponding issue on Github: https://github.com/electron/asar/issues/123
As you can see from the issue, this exploit has been known for 2 years and probably longer than that. As I said (November 2018) in the linked issue, I believe it's only a matter of time before Skype/Slack/VSCode gets packaged up with malicious code and flies under the radar of SmartScreen and Gatekeeper. It probably won't be downloaded from the official websites but there are plenty of other ways of distributing the software. I get the feeling that the Electron team aren't taking it too seriously. I think this has the potential for a really dangerous exploit.
My startup (ToDesktop[1]) uses Electron and I've put a huge effort into securing certificates on HSMs (Hardware Security Modules). But it's mostly a pointless exercise when a hacker can simply edit the javascript source.