Hacker News Reader

Comment by tptacek | Hacker News Reader

The big problem with Electron isn't that it forces you to keep up with Chrome, although that's important too, but rather that it links Node.js with content-controlled Javascript, so that DOM corruption vulnerabilities can be leveraged for RCE, even in the absence of a Chrome vulnerability. Most Electron RCEs that you've read about had nothing to do with Chromium.

There's a whole process for evaluating and auditing Electron applications, which is harder to do than auditing (for instance) a native mobile application or, probably, even a native desktop application.

View on HN

> rather that it links Node.js with content-controlled Javascript, so that DOM corruption vulnerabilities can be leveraged for RCE, even in the absence of a Chrome vulnerability

Can you explain this further? How is it different than a web-app with a NodeJS backend?

Imagine you’re writing Javascript code on a webpage. You write `const fs = require(‘fs’)`. It throws an error because the browser has no idea what “require” or “fs” are.

In electron, you can configure your page to be interlinked with node, so that you could write `const fs = require(‘fs’)` and import the Node filesystem module. This is a big feature of Electron, but it also opens you up to a whole host of vulnerabilities.

For instance, you are never supposed to spin up a WebView like this and then just load random URLs (this is emphasized in the docs when they’re explaining how to do this). However, if you did, untrusted code on a random webpage would have access to the user’s filesystem.

[Edit now that I'm back on my laptop]: Here's the section of the docs that covers this security concern: https://www.electronjs.org/docs/tutorial/security#isolation-...

> Under no circumstances should you load and execute remote code with Node.js integration enabled. Instead, use only local files (packaged together with your application) to execute Node.js code. To display remote content, use the <webview> tag or BrowserView, make sure to disable the nodeIntegration and enable contextIsolation

In electron the UI javascript is running in a separate process than the node javascript. They can communicate through Electron's IPC channel.

I wouldn't be too surprised if it could be exploited, but it's not as easy as require('fs'). Instead you have to send messages through the pipe and you'd have to know how to exploit the handlers at the other end in the NodeJs process.

https://www.electronjs.org/docs/api/ipc-main

I was on a phone before and didn't have the docs pulled up, but the thing I was referring to is called nodeIntegration (it's a boolean you set in the webPreferences object in the options object you pass to the BrowserWindow constructor).

This section of the docs explains it a bit better: https://www.electronjs.org/docs/tutorial/application-archite...

> Electron exposes full access to Node.js both in the main and the renderer process.

TIL, thanks.

Why would they need a node process? Are there things an Electron app needs to do that isn’t possible from the Chrome runtime? And more importantly, why would they need to directly link with the DOM?

Sorry I am not very familiar with Electron.

Since bridging Node.js with the DOM is basically the whole point of Electron, it's a little tough for me to answer this question. Yes, there are things Electron apps need to do that you can't do from standard Chrome.

Well, one very simple example is access to filesystem. You can't do that from Chrome but can from node. In this particular case for example WhatsApp could have a cache of the images and videos attached to a conversation, without having to obey the limits of local databases imposed by PWAs.

The way I author my Electron apps to avoid this is to have a HTTP/Websocket server spin up at a random port, and then use that process to open an Electron window, with Node integration disabled.

This then becomes exactly the same as writing a web app, with anything that cannot be done by the renderer (Ex: file access) being done by the 'server'. Always wondered why this was not an officially strictly recommended way of doing this.

Because not everyone is making an app that talks to the internet with Electron.

Electron comes with a renderer/server architecture out of the box?

https://www.electronjs.org/docs/tutorial/application-archite...

It does, but:

> Electron exposes full access to Node.js both in the main and the renderer process.

Latency. The electron IPC is way faster than using web sockets and the ability to have node modules in the renderer makes some task actually feasible. I've worked on apps that were quite possible to do with electron but were completely out of question in more classic environments like Cordova or in Android/iOS web views.

Correct me if I misread. You're leaving ports open on a customer machine, which has its own potential for security issues, even if you bind to localhost.

Wasn't there a Mac app that recently got a lot of flack for this?

IIRC the app you're talking about is Zoom's mac client.

Yes that's correct. And AFAIK the consequence was that any browser tab capable of running javascript could make HTTP requests to localhost and access the webcam.

Just remember that authentication and origin checking is completely up to the websocket server. Any random page in a browser can talk to your websocket cross origin, and it's up to your server to check the "Origin" header to make sure it's actually your app on the other end.

If you base it origin couldn't that have false positives too? Like say other, less privileged apps?

Yes and no. Recently browsers started assuming that a response without CORS headers it unsafe unless from the same origin. So even though you can make a request if it fails preflight it will not even reach your server.

You can try this by opening a console on any webpage and trying to do fetch requests or add img tags to the page that are loading resources from localhost.

Just in case, you may want to listen on localhost and use MTLS or TLS+preregistration between the client and the server.

Or just use unix domain sockets and named pipes, and then you don't have users complaining that you've used some random port that they want to use for some reason.

But really for stuff like file system access just use the node APIs, don't shuffle this stuff through any hand rolled IPC.

> without having to obey the limits of local databases imposed by PWAs

If you're shipping your own Chromium, shouldn't it be trivial to remove those limits?

Wait, are you telling me there are TWO javascript engines in a typical Electron app?

ermagerd

That obviously depends on what your Electron app wants to do.

Let's say you're writing an IDE in it. How would you invoke compilers & debuggers, cache filesystem/type information, state, etc. without breaking out of the browser sandbox somehow?

Can you imagine reading this comment 100 years ago?

They would be amazed, as this sounds like incredibly advanced technology, and maybe disappointed when they find it was all about imaginary objects in an interactive projector.

John Titor would be proud.

His predictions are correct, or at least they were until he made them.

How about reading it the day Node.js was first released.

Reply on news.ycombinator.com