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

81–90 of 138 posts

Re: Basic Electron Framework Exploitation

#81

Post by marshallofsound »

saagarjha wrote: post #4

> The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed Resources on macOS get signed as part of the application bundle. I wonder why this isn't possible for Electron apps as well.

Hi Electron maintainer here

ASAR files are signed as part of the application bundle. The issue is that folks don't understand how gatekeeper works so let me try explain it here.

When you download an application from the internet, macOS initially considers it "quarantined". When a quarantined application is first opened gatekeeper scans it _completely_ and if it's happy removes the quarantine tag and let's it launch.

Once that quarantine tag is removed, gatekeeper will never run a complete check of that application again. Meaning the ASAR files are validated once, when the application is first launched.

What people are seeing here is they're taking an application that gatekeeper has already signed off on, modifying it, and then asking why gatekeeper didn't stop them.

If you took that modified application, zipped it up, uploaded it somewhere, downloaded it again and tried to run it, it would NOT work. Gatekeeper would boot that invalid application to the shadow realm.

Re: Basic Electron Framework Exploitation

#82

Post by marshallofsound »

seandougall wrote: post #74
pimterry wrote: post #47

I'm unclear about how this attack works. The article says: > attackers could backdoor applications and then redistribute them Most distribution mechanisms however ship a single signed bundle, containing & thereby signing the entire application, including resources like ASARs. Any that don't sign the application are of course vulnerable to all sorts of trivial attacks (replace the whole binary with anything you like).…

> For macOS for example, all resources (including ASAR files) are signed, and macOS makes it intentionally difficult to install anything that isn't signed. I just tried this with Slack on macOS, and it launched without a single complaint about code signing. It would appear that either the ASAR files are not included in the signature, or the OS doesn't check the entire application bundle on every launch. (Edit: That s…

Hi Electron maintainer here, I explained how gatekeeper and asar validation plays in with macOS codesigning here --> https://news.ycombinator.com/item?id=20637791

Re: Basic Electron Framework Exploitation

#83

Post by ilikehurdles »

floatingatoll wrote: post #76
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…

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 checking the "CodeResources" file in the apps signature.

> You can't re-distribute the app without gatekeeper completely shutting you down.

[1]: https://news.ycombinator.com/item?id=20637738

Re: Basic Electron Framework Exploitation

#84

Post by [deleted] »

SamuelAdams wrote: post #17

For those that do not read the article: >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 signature is not modified.

[deleted]

Re: Basic Electron Framework Exploitation

#85

Post by cloudego »

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…

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.

Re: Basic Electron Framework Exploitation

#86

Post by dvt »

cloudego wrote: post #85
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…

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…

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

Re: Basic Electron Framework Exploitation

#87

Post by saagarjha »

marshallofsound wrote: post #81
saagarjha wrote: post #4

> The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed Resources on macOS get signed as part of the application bundle. I wonder why this isn't possible for Electron apps as well.

Hi Electron maintainer here ASAR files are signed as part of the application bundle. The issue is that folks don't understand how gatekeeper works so let me try explain it here. When you download an application from the internet, macOS initially considers it "quarantined". When a quarantined application is first opened gatekeeper scans it _completely_ and if it's happy removes the quarantine tag and let's it launch.…

Once you can establish that the main application binary is codesigned correctly (which AFAIK macOS will do at each launch?), why can't put signature checks into that to validate the ASAR files?

Re: Basic Electron Framework Exploitation

#88

Post by ilikehurdles »

marshallofsound wrote: post #81
saagarjha wrote: post #4

> The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed Resources on macOS get signed as part of the application bundle. I wonder why this isn't possible for Electron apps as well.

Hi Electron maintainer here ASAR files are signed as part of the application bundle. The issue is that folks don't understand how gatekeeper works so let me try explain it here. When you download an application from the internet, macOS initially considers it "quarantined". When a quarantined application is first opened gatekeeper scans it _completely_ and if it's happy removes the quarantine tag and let's it launch.…

So this sounds like a non-issue -- or at least not a new or novel one. How did this get published so far and wide?

Re: Basic Electron Framework Exploitation

#89

Post by seandougall »

marshallofsound wrote: post #79
seandougall wrote: post #72

Earlier quoted context omitted.

On macOS, if my understanding of the current situation is correct, code signing normally covers all binaries in an application bundle, including binaries in all bundled frameworks. What's different about Electron is that it puts application code, which is not a binary, into the Resources/ directory, which is not signed. I just tried this out with Slack on macOS, and it did work... almost as advertised. I had to use s…

Hi, Electron maintainer here. > I just tried this out with Slack on macOS, and it did work 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 applic…

Thanks for taking the time to reply! Like many here, I've been a critic of Electron, but I think it also does some amazing stuff, and I'm sorry you have to go into PR maintenance mode over such a weaksauce article.

I was coming back to follow up and say that that's exactly what I found -- running `codesign --verify` does show the modification. It makes sense that Gatekeeper wouldn't re-verify a 185 MB bundle on every launch, which makes me wonder if there's something else macOS could be doing at the FS level to see if any files have been modified and trigger a new check.

At any rate, while I don't quite take back what I said about application code in Resources/, I do take back the implication that it had anything to do with this; I suppose there doesn't seem to be anything Electron-specific about TFA, other than that exposing raw JS lowers the bar for who can write the code to inject. (Assuming you can get FS access to inject code in the first place, of course.)

Re: Basic Electron Framework Exploitation

#90

Post by [deleted] »

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…

[deleted]
Post reply on HN