Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project status #6

Open
zeke opened this issue Mar 14, 2017 · 7 comments
Open

Project status #6

zeke opened this issue Mar 14, 2017 · 7 comments

Comments

@zeke
Copy link

zeke commented Mar 14, 2017

👋 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

🧅

@james-see
Copy link
Owner

james-see commented Mar 14, 2017

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

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

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

  1. do I have plans to continue to develop it

yes.

@tarruda
Copy link

tarruda commented Mar 14, 2017

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: electron/electron#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: electron/electron#8815. The progress on enhancing the sandbox feature can be followed here: electron/electron#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
Copy link
Owner

@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: electron/electron#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
Copy link

tarruda commented Mar 15, 2017

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
Copy link
Owner

@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
Copy link

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
Copy link
Owner

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants