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

111–120 of 138 posts

Re: Basic Electron Framework Exploitation

#111

Post by benbristow »

miyoyo wrote: post #107
benbristow wrote: post #59

Earlier quoted context omitted.

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.

Except to run Electron applications you need to distribute the open source Electron runtime. Just so happens that it's shipped with every application.

True. With all binaries you’re going to be running software that’s bundled and you’re unsure what’s going on fully.

Send me the source for an Adobe Air application though and I still need to download Adobe Air proprietary tools to run it.

For an Electron application I can run it directly from open source tooling.

Re: Basic Electron Framework Exploitation

#112

Post by pvg »

hnbroseph wrote: post #110
pvg wrote: post #91

Earlier quoted context omitted.

The claim is it's easier to bypass some app integrity protection mechanisms when the target is an Electron app.

"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.

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.

Re: Basic Electron Framework Exploitation

#113

Post by floatingatoll »

ilikehurdles wrote: post #83
floatingatoll wrote: post #76

Earlier quoted context omitted.

3) is not a valid protection on macOS once the application is copied away from the signed DMG (which is then discarded). macOS code signing does not extend to Contents/Resources/ which, unfortunately, is where — without exception — every application on my system stores 'electron.asar'. /Applications/VMware Fusion.app/Contents/Library/VMware Fusion Applications Menu.app/Contents/Resources/electron.asar /Applications/b…

This response from elsewhere [1] seems relevant: > Here's the thing with how gatekeeper works, that application had already passed gatekeeper and will never be _fully_ validated ever again. > If you zipped your modified Slack.app up, uploaded it to google drive, and downloaded it again. Gatekeeper would 100% reject that application, the ASAR file is included as part of the application signature. You can prove this by…

Hooray! I am glad to be wrong. For others looking to test this,

    $ codesign -dv /Applications/xyz.app
    ...
    Sealed Resources version=2 rules=13 files=122
    ...
For version=2, all resources are signed.

Re: Basic Electron Framework Exploitation

#114

Post by zerkten »

giancarlostoro wrote: post #94
dvt wrote: post #67

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 tha…

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.

It is something that gets attention when you have a defense-in-depth approach. Look at https://www.python.org/dev/peps/pep-0551/ and https://www.python.org/dev/peps/pep-0578/ for Python.

Re: Basic Electron Framework Exploitation

#115

Post by dvt »

pvg wrote: post #112
hnbroseph wrote: post #110

Earlier quoted context omitted.

"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.

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.

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."

Re: Basic Electron Framework Exploitation

#116

Post by dvt »

anonymous6969 wrote: post #99
dvt wrote: post #86

Earlier quoted context omitted.

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 vulnerabil…

The interesting thing to me is that the techniques you are talking about get lit up like a Christmas tree by some modern endpoint protection products, whereas a backdoored Electron app is squeaky clean on Virustotal...

This is untrue. A "backdoored" native app (i.e. an app where an executable or DLL was modified) would also be squeaky clean.

Re: Basic Electron Framework Exploitation

#117

Post by floatboth »

saagarjha wrote: post #96
xigency wrote: post #58

Earlier quoted context omitted.

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.

Java applications use the look that the system provides.

That is, Swing has some mediocre Mac and Windows themes. JavaFX comes with only a custom design.

Re: Basic Electron Framework Exploitation

#118

Post by t0astbread »

giancarlostoro wrote: post #94
dvt wrote: post #67

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 tha…

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.

Why just scripting languages? Can't I replace compiled binaries as well?

Re: Basic Electron Framework Exploitation

#119

Post by t0astbread »

tomatotomato37 wrote: post #23
mavdi wrote: post #3

Electron is the new Flash. Change my mind. ¯\_(ツ)_/¯

Makes sense. Instead of bringing slow risky software to the web just so people didn't have to learn javascript, it brings slow risky software to the desktop just so people don't have to learn C.

Why risky? This vulnerability applies to any runtime or program that isn't signed as far as I can tell. It's not specific to Electron or JavaScript.

Aside from that, I don't know what the situation is in the year 2019 but does C still allow you to easily mess up memory management?

Re: Basic Electron Framework Exploitation

#120

Post by dvt »

FreakLegion wrote: post #108
pimterry wrote: post #71

Earlier quoted context omitted.

I think its been exacerbated significantly by the reporting elsewhere: 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…

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,…

> 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 (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.

Post reply on HN