Software contains remote code execution vulnerability via insecure autoupdate mechanism

[sneak]

Expected Behavior

The code I downloaded is the code that runs on my machine, and remote attackers cannot change it without permission.

Current Behavior

The software automatically downloads arbitrary code from a remote server without consent, and runs it, granting control of the local system to anyone who controls the update server.

The person in control of the update server can then use this remote code execution ability to download endpoint keys, message plaintexts, etc.

Possible Solution

Require affirmative consent for autoupdates, default autoupdates to off.

Steps to Reproduce

Run the bridge software.

Version Information

current: da76784

Context (Environment)

I was running the bridge in a docker container and it downloaded new unchecked code without consent which ran on the next launch.

Detailed Description

Autoupdates must be approved by the user before being installed.

Possible Implementation

Signal does it by requiring a click before replacing the code:

signalapp/Signal-Desktop#4578

[sneak]

Note that between this and #495 I am now convinced that the Proton developers do not respect my privacy or my rights to my own computer, and I'm going to be migrating all of my domains away from Protonmail. It's simply not worth the hassle to maintain my own Dockerfile to patch out these insane defaults.

[ashrude]

I appreciate what you're trying to do but how about instead of attacking proton and shenxn, why not focus on real issues, or next time bring it up without being so hostile.

[EntropyAndAnomie]

Sneak: Please leave.

Proton balances privacy & usability better than the adware webmail companies. The 1% of us who care about privacy appreciate them. Except for the worst 10% of the privacy community - they appreciate nothing because they are inherently oppositional, assigning malevolence to every decision they wouldn't make themselves.

I'm not sure Proton thought of how to handle auto-updates specifically in Proton Bridge, such a tiny product for them. But I'm sure they debated the obvious drawbacks of auto-updates across their product portfolio, and whether risks of a supply-chain attack justified the also-well-established risk of driving more "casual" users off of the product with pop-ups every 2 weeks. It's not the obvious choice that you make it out to be - casual users (the biggest bucket of paying Proton customers) who get approval requests for something as common as an app update will quickly train themselves to always hit OK until they can switch back to Gmail.

It doesn't matter how obviously dumb that is to us nerds in a Git issue thread; casual users' poor decision-making IS our problem, because those users fund Proton's existence. Nerds in a Git Issue thread do not fund Proton. We are financially inconsequential.
Proton Devs do probably appreciate us more than casual users though! Or, maybe they don't, with caustic stuff like this getting thrown at them.

To Proton Bridge's Maintainers: Sneak has a point (although there's no reason to use everything with a point as a weapon). Especially among Bridge users (more proficient, more accepting of interruptions than average Proton users) a prominent note on how to disable telemetry and require acceptance prior to pushing new code would be welcome/expected. A link to what is being shared by the telemetry, and why, is also something I'd really like to see. But for web or phone mail apps, for which your median user population is less savvy, less paranoid, and less patient, I do get why this stuff is enabled by default. Even if I'd prefer it not be.

One idea that probably wouldn't lead to casual user egress - maybe ask all Proton users one time whether they'd prefer a "Default" or "Custom" configuration of Proton apps when they first use them. People who choose "Custom" could get a "Choose your privacy options" list for this stuff, explaining the impacts of selecting 'yes' or 'no' to auto-updates and telemetry to help you learn about crashes, and to better understand the client app configuration so you can tweak server/client interaction to hopefully reduce them.

[sneak]

It’s not an attack to point out that the privacy story and the privacy actions don’t match. This is plainly a vulnerability and reporting it to Proton so they can fix it is me doing something that explicitly benefits them (as well as their user base).

Your hostility is unwarranted and unprofessional.

[sneak]

fwiw you are violating the contributor code of conduct with your comment.

https://github.com/ProtonMail/.github/blob/main/CODE_OF_CONDUCT.md

As such, we are committed to providing a friendly, safe and welcoming environment for all

[EntropyAndAnomie]

I don't know how this "I know you are but what am I" stuff became so rewarding to folks online over the last 5 years.

You asserted that the product contained "spyware" because it phones home. I professionally pointed out - that's hostile. Not welcoming, friendly or positive. Being hostile and then yelling "your response breached the code of conduct" at the person who called you on it doesn't make you suddenly look like the victim. And a code of conduct does not exist to prevent me from saying a community member is being a jerk, obviously.

I didn't just reply to call out hostility. The actual issue you are bringing up is legitimate and important. I think it deserves attention. It didn't seem to be getting any. I was concerned that the issue may have been percieved as less important than it actually is because it was wrapped in invective - "the type of stuff hostile people bring up". So I re-issued the request more amicably, in the hopes our valid concerns might attract some attention.

Along the way, I also wanted to express appreciation for the work done by the developers. I still don't want that to get lost here. Proton Devs who read our messages here could make more money if they worked at one of the companies that sell our data for profit. I'm not implying they are saving children from war or curing world hunger... but they aren't Facebook or Pegasus, and they aren't making big bucks off of "Spyware". They aren't checking our mail client configuration so they can sell our data. I don't question their comoetence or motivation; I did want to acknowledge there are some legitimate counter-arguments to doing what the two of us want done. I just think that, in the case of Bridge especially, the balance of the path they chose isn't ideal.