4 ms·

This 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

by dvt 7y ago

This 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/ https://www.microsoft.com/en-us/research/project/detours/ [2] https://defuse.ca/exploiting-cpp-vtables.htm https://defuse.ca/exploiting-cpp-vtables.htm

cloudego 7y ago
I’m not sure why you’re so upset by this. Electron is installed on our machines and deserves to be scrutinized. 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.
- dvt 7y ago
  It's clickbaity and low-effort because this is no more an "exploit" than running a random .exe is an "exploit." It can be "fixed" by always installing software from trusted vendors and not running random executables you download from IRC. In other words, it doesn't even really qualify as an attack vector. Electron isn't any more vulnerable than any given native app. 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-17481 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1748...
  - pvg 7y ago
    The claim is it's easier to bypass some app integrity protection mechanisms when the target is an Electron app.
    - hnbroseph 7y ago
      "easier" than what? and is it particularly noteworthy? if malicious code has write access to any given app's constituent files, there's effectively no app that's hard to subvert.
      - pvg 7y ago
        Easier than apps that are better covered by system app integrity protection? I'm not sure what's unclear about this, it's right in the writeup.
        dvt 7y ago
        If you're talking about installing apps, every installed app needs to be signed (unless you ignore Windows/macOS warnings). If you're talking about injection or modifying program files (be them executables, DLLs, or ASARs) post-install, every app is equally-vulnerable. There is no functional difference between a native app or an Electron app in that regard, so maybe you can clarify what you mean by "system app integrity protection."
        pvg 7y ago
        so maybe you can clarify 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.
pimterry 7y ago
I think its been exacerbated significantly by the reporting elsewhere: https://arstechnica.com/information-technology/2019/08/skype-slack-other-electron-based-apps-can-be-easily-backdoored/ https://arstechnica.com/information-technology/2019/08/skype... 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.
- deleted 7y ago
  [deleted]
- FreakLegion 7y ago
  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) 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.
  - dvt 7y ago
    > Only drivers have to be signed on Windows 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 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.
giancarlostoro 7y ago
This is like saying a Python or Ruby application could be exploited if someone snuck code into your machine. This is a known scripting language "flaw" that nobody cares deeply about.
- zerkten 7y ago
  It is something that gets attention when you have a defense-in-depth approach. Look at https://www.python.org/dev/peps/pep-0551/ https://www.python.org/dev/peps/pep-0551/ and https://www.python.org/dev/peps/pep-0578/ https://www.python.org/dev/peps/pep-0578/ for Python.
- t0astbread 7y ago
  Why just scripting languages? Can't I replace compiled binaries as well?

by dvt 7y ago

cloudego 7y ago

I’m not sure why you’re so upset by this. Electron is installed on our machines and deserves to be scrutinized. 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.

dvt 7y ago
It's clickbaity and low-effort because this is no more an "exploit" than running a random .exe is an "exploit." It can be "fixed" by always installing software from trusted vendors and not running random executables you download from IRC. In other words, it doesn't even really qualify as an attack vector. Electron isn't any more vulnerable than any given native app. 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-17481 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1748...
- pvg 7y ago
  The claim is it's easier to bypass some app integrity protection mechanisms when the target is an Electron app.
  - hnbroseph 7y ago
    "easier" than what? and is it particularly noteworthy? if malicious code has write access to any given app's constituent files, there's effectively no app that's hard to subvert.
    - pvg 7y ago
      Easier than apps that are better covered by system app integrity protection? I'm not sure what's unclear about this, it's right in the writeup.
      - dvt 7y ago
        If you're talking about installing apps, every installed app needs to be signed (unless you ignore Windows/macOS warnings). If you're talking about injection or modifying program files (be them executables, DLLs, or ASARs) post-install, every app is equally-vulnerable. There is no functional difference between a native app or an Electron app in that regard, so maybe you can clarify what you mean by "system app integrity protection."
        pvg 7y ago
        so maybe you can clarify 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.

pimterry 7y ago

I think its been exacerbated significantly by the reporting elsewhere: https://arstechnica.com/information-technology/2019/08/skype-slack-other-electron-based-apps-can-be-easily-backdoored/ https://arstechnica.com/information-technology/2019/08/skype... 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.

deleted 7y ago
[deleted]
FreakLegion 7y ago
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) 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.
- dvt 7y ago
  > Only drivers have to be signed on Windows 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 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.

giancarlostoro 7y ago

This is like saying a Python or Ruby application could be exploited if someone snuck code into your machine. This is a known scripting language "flaw" that nobody cares deeply about.

zerkten 7y ago
It is something that gets attention when you have a defense-in-depth approach. Look at https://www.python.org/dev/peps/pep-0551/ https://www.python.org/dev/peps/pep-0551/ and https://www.python.org/dev/peps/pep-0578/ https://www.python.org/dev/peps/pep-0578/ for Python.
t0astbread 7y ago
Why just scripting languages? Can't I replace compiled binaries as well?