Community-edition: General approach to security

[TwizzyDizzy]

Steps to reproduce

1. Open Rambox
2. Go menu "Help" > "About Rambox"
3. Look at every version number

Expected behavior

• very recent, if not latest version of every component involved

Actual behavior

• outdates NodeJS
• outdated Chromium
• outdated Electron

ENVIRONMENT

Rambox: v0.5.3
OS: Linux, Ubuntu 16.04
Arch: x64

When it comes to security, I feel there's only two approaches:

• Keep the user as safe as possible by having every component updated very, very regularly
• Keep the user safe by not publishing your software (with known security vulnerabilities, known to be critical)

This is not meant as an insult, but rather as a strongly worded urge to update the components you're using in Rambox! By handling it the way you're currently handling it, you're actually putting your users at high risk knowingly.

Cheers
Thomas

[capi]

I am only a very short-time user of Rambox, but the reason I switched over from "Franz" is, that the development of Franz seems to have stopped and it is using very outdated versions. I was hoping, that this active community will be very up-to-date with the "critical components" (Electron, Chromium, Node).

I never developed for Electron, so I'm not ready to contribute now, but I hope to be able in the future. I would also strongly urge that this could become an always-ongoing priority for this project.

[TwizzyDizzy]

It seems as though @saenzramiro has read this post and acted accordingly.

There is a pre-release of 0.5.8 that updates the dependencies.

First and foremost: thank your for taking that issue seriously :). Have you taken measures to update the dependencies continuously?

Cheers
Thomas

[TwizzyDizzy]

0.5.9 is now released and contains

• [x] chromium, latest version (58.0.3029.110)
• [ ] electron, v1.7.1 beta (v1.7.2 beta is available)
• [ ] nodejs, 7.9.0 (7.10.0 is available) - also upgrading to nodejs 8 LTS _might_ be in order

Cheers
Thomas

[errotu]

When I check the "about" page of Rambox I see the following information:

Version: 0.5.9
Platform: linux (x64)
Electron: 1.4.16
Chromium: 53.0.2785.143
Node: 6.5.0

Any idea why the Electron, Chromium and Node version aren't up to date in my Rambox? I use rambox on Arch Linux and installed it via AUR.

[TwizzyDizzy]

Any idea why the Electron, Chromium and Node version aren't up to date in my Rambox? I use rambox on Arch Linux and installed it via AUR.

@errotu: this has got nothing to do with Rambox. The maintainer of Rambox in the AUR ("flying-sheep") needs to update his package according to the latest release. His last package update is from 2017-05-30.

Packages in the AUR are maintained by users, who might or might NOT be the actual developers of the software in question. So you should contact that maintainer.

Cheers
Thomas

[errotu]

@TwizzyDizzy: Thanks a lot for the advice! Actually, the AUR package uses the current version of Rambox but is - if I understood the PKGBUILD correctly - using an older version for building the environment. I don't understand why.
Whatever, I switched to rambox-bin in the AUR which is using an up-to-date Rambox version and environment.

[TwizzyDizzy]

0.5.12 is the order of the day with all main components being outdated:

• [ ] chromium, 58.0.3029.110, (60.0.3112.113 is available)
• [x] electron, v1.7.5
• [ ] nodejs, 7.9.0 (nodejs 7 is outdated and no longer supported) - upgrading to nodejs 8 LTS is recommended

Cheers
Thomas

[TwizzyDizzy]

Oh... and sorry if that feels like bossing around. That's not my intention. In the end, I too, have an obvious interest in Rambox being secure so I thought I might help with that information so everybody can be as secure as possible.

Cheers
Thomas

[TwizzyDizzy]

Well then. Under these circumstances (no reaction, no communication) I have to stop using Rambox. This is also my recommendation to anyone reading this. I will not put my security at risk because of one application. A pity, because I liked it quite a lot.

Cheers
Thomas

[capi]

@TwizzyDizzy I am concerned about this as well. Maybe if we tried helping by testing with newer dependencies and providing pull requests. We could try to help out and not let the maintainer alone with all the work.

[TwizzyDizzy]

Hi @capi, I'm no developer, hence I'm not qualified. What I can do is to offer testing new (pre-)releases against my local setup, which I am hereby offering.

And let me keep one thing straight. I am sympathetic to the struggles of FOSS developers stemming the weight of their projects (alone or with very few people). That's why I had this option in the initial post:

Keep the user safe by not publishing your software (with known security vulnerabilities, known to be critical)

This is not to offend anyone. Either you (and the developers that are interested in this software and want to help) maintain a project in a secure manner, or you don't. But keeping an insecure software available is just not fair to the people using it. Unfortunately people would still be using your software if you would de-publish it, yet then it is not your fault anymore.

Cheers
Thomas

[TwizzyDizzy]

0.5.13 is the order of the day:

• [ ] chromium, 58.0.3029.110, (61.0.3163.100 is available)
• [x] electron, v1.7.8
• [ ] nodejs, 7.9.0 (nodejs 7 is outdated and no longer supported) - upgrading to nodejs 8 LTS is highly advised

Cheers
Thomas

[TwizzyDizzy]

Hi @saenzramiro / all,

I have done a bit of research myself now. It seems as though nodejs and chromium come bundled with electron. So that means you can't upgrade chromium without having electron upgraded.

That being said, the latest electron beta seems to already use an outdated version of chromium. This leads me to the conclusion, that using an electron app is, in general, a security risk not worth taking. So the problem does not stem from Rambox, but from Electron.

Your lack of feedback is still irritating. Closing this issue now.

Cheers
Thomas

[capi]

@TwizzyDizzy I would not jump to the conclusion that running any Electron app is unsecure. Running one with a vulnerable Chromium inside is. Not all versions of Chromium are vulnerable, just because they are not the latest release. So I do think that it is more complex than your assessment based on version numbers alone.

[TwizzyDizzy]

Hi @capi,

I appreciate your feedback, and in fact, I hope to be wrong, but let's go through it piece by piece:

Running one with a vulnerable Chromium inside is.

true

Not all versions of Chromium are vulnerable

in itself: true, yet

just because they are not the latest release.

.. seems to be untrue, if I take https://en.wikipedia.org/wiki/Google_Chrome_version_history as the basis for my evaluation. At least it seems as though the last major version is discontinued, when there is a new major version.

If we take https://github.com/electron/electron/releases as the basis for further evaluation, we see that even electron v1.8.1 beta doesn't include a recent Chromium version (even though they at least upgraded to nodejs 8):

Upgraded from Chrome 58.0.3029.110 to 59.0.3071.115

But pretty please: disprove me (I mean it). I'd hate to think that every electron app was a security risk.

Cheers
Thomas

[capi]

@TwizzyDizzy While I do agree, meaning that it is discontinued doesn't immediately mean it's a security risk (one needs to be found first). And even then, it is not sure if every security issue effects an Electron app in question.

Same issue remains with any Android apk which uses a WebView component (until the OS and/or the WebView are updated on an OS level). Same applies to any iOS application that uses an embeded WebKit view. Same applies to any QT application that uses a WebView.
Advantage of the Android/iOS stuff: if the OS component is updated, it is also updated for any application using it.

Additional question is, if the application runs untrusted or trusted content in the application. In case of Rambox I'd go for "untrusted", since it's the content of both, external companies and external-user generated content. So yes, I am with your security concerns here. And yes, you are at risk with any Electron application that does not release with new versions of Electron. But you have the same issue with any e.g. QT application that uses embedded views.

Electron itself has a section of the documentation dedicated to this.

The bottom line is: if you executed trusted content, this update issue with Chrome is not that much an issue.
If you have untrusted content, then it is. Now the question remains: how do you classify Rambox and the content it is showing? Is it trusted as those are trusted external companies, or is it untrusted, since it also shows user-generated content that might not have been properly filtered by those external companies?

[TwizzyDizzy]

Hi Capi, thanks for your balanced feedback! :)

that it is discontinued doesn't immediately mean it's a security risk (one needs to be found first). And even then, it is not sure if every security issue effects an Electron app in question.

When in doubt, I'll go with the safest option here: I'd rather assume that there is a risk if I don't know better, than to assume that there is none.

The risk for the former being: being overly cautios and having "costs" (in terms of developer time spent in case of FOSS)
The risk for the latter being: potential compromising

I think, that indeed one cannot find a perfect answer for any case, as there always needs to be a balance between resources spent and effects achieved. But naturally, as the latter is not always measurable in terms of security gained, it's quite hard to get to that balance.

Same issue remains with any Android apk which uses a WebView component (until the OS and/or the WebView are updated on an OS level). Same applies to any iOS application that uses an embeded WebKit view. Same applies to any QT application that uses a WebView.
Advantage of the Android/iOS stuff: if the OS component is updated, it is also updated for any application using it.

True. I was kind of fearing the situation where we would weigh one evil against the other. The situation being bad in other places is, in my opinion, no valid reason to dismiss a bad situation at hand.

I feared, that we would say: look, the situation is kinda fucked everywhere, so let's just get on with it as best as we can (maybe that's the balance I was thinking of above).

Additional question is, if the application runs untrusted or trusted content in the application. In case of Rambox I'd go for "untrusted", since it's the content of both, external companies and external-user generated content. So yes, I am with your security concerns here. And yes, you are at risk with any Electron application that does not release with new versions of Electron. But you have the same issue with any e.g. QT application that uses embedded views.

True-ish. For Rambox, as did you, I would go with "Untrusted". And currently it's hard to think of a case where that would not be the case with an Electron App. But then again, I haven't seen enough of them, to be honest.

Electron itself has a section of the documentation dedicated to this.

Well the was quite worth the read, thanks for pointing it out to me! But I'm a bit shocked, I have to say...

A security issue exists whenever you receive code from a remote destination and execute it locally. As an example, consider a remote website being displayed inside a browser window.

No shit, Sherlock! Most of the Electron apps I've seen will do just that.

If an attacker somehow manages to change said content (either by attacking the source directly, or by sitting between your app and the actual destination), they will be able to execute native code on the user's machine.

So here we go: Potential game over with a non-recent browser.

We feel that our current system of updating the Chromium component strikes an appropriate balance between the resources we have available and the needs of the majority of applications built on top of the framework.

Game over again. In a world where 0days are dealt with on a daily basis that's just so fucking far from reality. As indicated above: yes, the argument concerning the resources is valid. Yet I'm kinda weary when it comes to trusting my security to that.

Is it trusted as those are trusted external companies, or is it untrusted, since it also shows user-generated content that might not have been properly filtered by those external companies?

In my mindset, there is no such thing as trusted entities. External input is potentially malicious, no matter the source.

Whilst I agree that this point of view might be a bit... let's say... totalitarian, I still think it's a better (or "more secure") perspective than one that is stemming from "trust".

It seems though, that we won't solve this problem here. I would just wish, that Electron would have had dealt with this obvious issue right from the beginning, as in: "hey, we're re-packaging a complete browser so let's do our very fucking best to make updating that component as easy and fast as possible."

So yeah... maybe that is the best one can do, maybe not. In the end, everbody has to draw their own conclusing based on their need for security and the threat-model they're facing.

Cheers
Thomas

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.