> 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 or VTable injection. 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.
Notably, according to that Ars Technica coverage:
> 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
That isn't in a claim in the original post, and doesn't seem to be true afaict: every distribution mechanism I can think of signs the entire distributable, so you really can't just modify the ASAR without breaking the signature. Windows & macOS both require you to only install from signed application bundles/installers (or at least they make it very difficult for you to use unsigned software). On Linux you could get caught out, but only if you download and install software with no signing/verification whatsoever, and that's a whole other can of worms.
If that claim were true this would be a bigger concern, but given that it's not I'm inclined to agree this is basically nonsense.
Only drivers have to be signed on Windows, and even then not all kinds until Windows 8. Also many apps, including Visual Studio Code, are available in 'run from USB' form, so there's no installer, just an archive you unpack and run. Those archives can be modified and redistributed without invalidating any of the PE signatures within, but since nobody pays attention to these signatures anyway and Windows doesn't enforce them, yeah, this is typical Black Hat-week PR nonsense.
This is half-true.
Windows and macOS both make it difficult to install self-signed (or unsigned) software. For example, I made http://www.lofi.rocks (an open source Electron-based music player) and I'm not going to spend like a few hundred bucks a year to have a non-self-signed cert. This makes both macOS and Windows complain when users install the app. More draconian practices (that "protect users from themselves") will make it even harder for independent open source devs like me to share cool projects with a wide audience.
The author presents the info clearly and even includes videos demonstrating the “technique,” so it doesn’t seem “low effort” and click-baity to me.
I’m not sure I can support your view that this is unworthy of attention or fix because of in-memory patching, etc. If I told my customers Not to worry about my product because there are much scarier ways they can get hacked elsewhere, they would still ask why I didn’t put my best effort into closing a known loop.
Compare that with an actual Chromium RCE vulnerability (a very clever PDF heap corruption exploit): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1748...
Backdoored ccleaner flagged as malicious by multiple ml based products:
Backdoored xmanager flagged by multiple ml based products: https://www.virustotal.com/gui/file/d484b9b8c44558c18ef6147c...
Countless other examples.
I didn't write this thing, I'm just saying that the claims it makes are not the claims you say it makes. 'Functionally equivalent' is a bit like 'Turing complete' - it makes it easy to say something so true it's not actually interesting.
It's not some major discovery or controversial claim that Electron apps are an even more convenient and easier-to-leverage vector for exploitation than regular old binaries. But writing some blog post about it (they didn't give the vuln a name, they didn't rent it shoes, they aren't buying it a beer) does not warrant the weird invective you're throwing at it.