Project status

[zeke]

👋 Hi there!

I work on GitHub's Electron team. Was wondering if anyone had built an alternative to Tor Browser using Electron. This project seems to fit that description. I just wanted to ask what the goals of this project are, what it does well, what it doesn't, and if you have plans to continue developing it.

Thanks

:onion:

[james-see]

@zeke thanks for the interest. I think most of what you are asking is already answered on the readme, but happy to answer here as well.

1. goals of project:

(taken from readme) I made this because I wanted a simple browser that auto-connected to my tor service running on my MacBook that I installed via homebrew. If you are running tor in OSX via homebrew, then this app will work out of the box if you follow the install instructions below.

to expand a bit, I wanted a very lightweight and locked down browser that I control and can build myself, thus electron made the most sense to me to use.

2. what it does well:

connects to tor out of the box assuming you have tor running as a service on your machine and allows you to browser .onion domains

3. what it doesn't do well:

ELECTOR DOES NOT guarantee security in the browser, specifically the issue I highlight in the readme, "ELECTRON has known security issues with using an unsandboxed version of chromium. The roadmap is to use the electron-prebuilt module from Brave browser since they re-sandboxed and fixed a lot of the security issues related to potential for XSS attacks." I am not sure Elector can ever fully guarantee security in the browser for the end user. End users will continue to do dumb things and zero days will continue to exist.

to expand a bit, without using a sandboxed version of electron-prebuilt then exploits could escape the confines of the browser and execute code on the users machine that is browsing to the malicious page. very scary stuff and this needs addressed.

4. do I have plans to continue to develop it

yes.

[tarruda]

guarantee security in the browser, specifically the issue I highlight in the readme, "ELECTRON has known security issues with using an unsandboxed version of chromium. The roadmap is to use the electron-prebuilt module from Brave browser since they re-sandboxed and fixed a lot of the security issues related to potential for XSS attacks

Last year I sent a PR that allows electron to use chromium sandbox: https://github.com/electron/electron/pull/6919.

Electron's sandbox option is still relatively limited in terms of what features it has access to, but I've recently made some effort to bring more features to sandboxed renderers: https://github.com/electron/electron/issues/8815. The progress on enhancing the sandbox feature can be followed here: https://github.com/electron/electron/issues/6712

You should be aware that sandboxing alone is not enough to guarantee security in the browser, especially for electron which allows the renderer to have full access to the browser permissions via IPC. I'm very interested in making electron more secure, and it would be great to know more about the work that was done in brave. Can you list some of the security issues that were fixed, beyond enabling sandbox?

[james-see]

@tarruda I am aware that sandboxing along is not enough to guarantee security in the browser, I was just highlighting that that is the most egregious problem I see right now with electron-browser security and how it specifically affects my implementation of it as a Tor browser (at least from a standpoint of when I originally wrote the code last year). For links to previous discussions on Brave forks and security issues with Electron: https://github.com/electron/electron/issues/5210 that was prior to your progress. Also what got me thinking about this issue in the first place was this blog post on scottlogic http://blog.scottlogic.com/2016/06/01/An-update-on-Electron-Security.html Both of these, I am aware, are before your progress.

It appears that I should above all else follow Electron's security guide (https://electron.atom.io/docs/tutorial/security/) to ensure that Elector is locked down to the extent possible to mitigate the most risk for the end user.

Do you have any suggestions and next steps to ensure this app's security that I can do from my end? I can push a new release after I make updates to the codebase based on your recommendations. Thanks for the input.

[tarruda]

Do you have any suggestions and next steps to ensure this app's security that I can do from my end?

As far as I can see, the biggest security hole in electron right now is the fact that any API from the browser process can be accessed via IPC.

It is not difficult to see why this makes the benefits provided by chromium sandbox very shallow: The sandbox is an extra OS-provided layer of defense against exploits(in blink/v8) that would allow an attacker to take control of the renderer process, but an attacker that controls the renderer process can also send any message via IPC. This is not an issue with chromium because its renderers are limited in what IPC messages they can send(eg there's no IPC that gives full access to the browser API like in electron).

The simplest idea I have to fix this security hole is to make electron treat sandboxed renderers as unstrusted by default. This means electron would ignore most IPC from sandboxed renderers, with exception to IPC that are used to preload a script and to send/receive messages to/from a trusted parent renderer(which would also be sandboxed, but explicitly marked as trusted by the electron app).

To answer your question: Running electron with --enable-sandbox command-line switch is a first step. Even with the problems described above, a sandboxed renderer doesn't have node.js running, which is already a big gain in terms of security(less code for attackers to exploit). In the next weeks I plan to send more PRs to improve sandbox mode both in features and security.

[james-see]

@tarruda thank you for this explanation & recommendation. I am going to work on the next version and release the compiled version with these security enhancements in place.

[kontrollanten]

Do you have any thought about modularize this package so the Tor part can be a standalone npm package to be used within other applications? I haven't dived into your app yet, but I'll do that in the next week. If it's okey with you, I'm interested in breaking out the Tor parts to a single module

[james-see]

@kontrollanten Yes, it is already modularized. Tor is installed separately by the user. It is a prerequisite of Elector. So what you are asking about is already explained in the Readme in the install section (line 39).