Signal no-intervention update grants RCE to Signal developers and others

[sneak]

• I have searched open and closed issues for duplicates

Bug Description

Signal automatically downloads new code and places it on my machine to be run without my interaction or consent.

This code could contain malicious software, and I am presented no opportunity to stop this process.

No-interaction autoupdate that cannot be disabled is unacceptable in security software, as it allows anyone who compromises the release process (or any of the credentials that allow the developers to operate the release process) to automatically download malicious code to my machine without my intervention.

Steps to Reproduce

1. run signal
2. there is no step two. code you've never seen will be automatically downloaded to your machine, and will run the next time you (or anyone else) launches Signal.

Expected Result:

Auto-update requires an opt in from the user to grant Signal developers this ability to automatically execute unreviewed apps or code.

Downloading and running of updates without user intervention or approval are, by definition, remote code execution (RCE) ability to whoever can publish updates, as well as whoever can coerce those people to publish updates (e.g. national governments or militaries).

Platform Info

Signal Version: v1.36.3

Resolution

The ability to disable no-intervention updates is essential. This is not a "feature request": without this, any machines running this software are vulnerable to attack by anyone who can compromise the release process, including hosting providers and many others.

Most users will, of course, wish to enable automatic updates, and Signal developers of course want everyone running the latest authorized version. The problem is that software that replaces its own code from the network without user intervention means that it will also run any unauthorized version released, as well. A subset of the userbase relies, possibly even for their own physical safety, on the ability to run only authorized Signal releases.

Please provide us an option for disabling automatic update, and close the RCE hole.

[sneak]

Note that autoupdates can be (and, in my case, are) disabled on iOS mobile (as, due to platform security concerns just like this one apps are not allowed to replace their own code without user intervention) without ill effect.

The app, if too far out of date, just displays a message requesting that the user update.

[henricook]

Which platform is affected by this @sneak ?

[sneak]

I assume it affects all of them, but this was identified on macOS.

[Nisc3d]

No, on Linux I update through my Package Manager when I want it.
The last time I used windows there was an alert, that asked if you want to update. Can someone confirm that?

[jromero2k]

No, on Linux I update through my Package Manager when I want it.
The last time I used windows there was an alert, that asked if you want to update. Can someone confirm that?

It's been a long time peeve of mine.. it just auto "updates" or whatever it's deciding to do (macOS here)

[JanZerebecki]

There are other ways than the suggested solution to improve security for all Signal users. Such a solution would also increase security more than auto updates for those few who are helped by disabling auto updates. Disabling auto updates may improve security for only a few of all Signal users (those that read all the code and rebuild to verify they can reproduce the update and only then install an update). These few are most likely not the most at danger users of Signal (otherwise they wouldn't have time to verify Signal).

For such a solution you need:

• Append only log for updates and all their signatures.
• A way to make sure just one honest response that there exists a signature that is not included in the log can still reach you.
• Additional signatures of a code commit that state that someone verified or failed to verify a security property of the code by a stated means.
  • Some of these can be done by automated systems. Any CI results should create these. Verifications of reproducible builds should create these.
• A advanced user only way to choose which signatures to require for an auto update.

[JanZerebecki]

Note: an even lower hanging fruit here would be to git commit sign all commits and tags. This isn't currently done. If any Signal developers with merge rights like help with that, feel welcome to reach out directly to me.

[sneak]

I don't think that signed commits add any security benefit whatsoever. It's also off topic for this issue, please open a different one (and optionally tag me) if you wish to discuss it further, but do not do so here.

[sneak]

Ahh, got it:

Note that both of those buttons mean "run this new software you haven't inspected". Dangerous!

[sneak]

"Later" it gets more demanding, too.

[jimio-signal]

Hi!

A few things here:

• Classifying software updates as Remote Code Execution vulnerabilities is a stretch, and it looks like some related philosophical discussion has taken place already over in another project @ Security: Bitwarden Desktop app grants RCE to Bitwarden developers. bitwarden/desktop#552.
• Our releases are digitally signed, and signatures are verified prior to any code running on your machine, which means that “hosting providers and many others” can not compromise the release process.
• We do not automatically run code that is downloaded as part of an update. When an update is available, our client will retrieve it and prompt you to restart to run the latest release. If you’d like to look at the commits, code, and release notes prior to restarting and running Signal, you may do so here: https://github.com/signalapp/Signal-Desktop/releases
• Our desktop updates are served from updates.signal.org, and that domain is not used for any other purpose in the application. If you would like to modify the DNS configuration of your machine, your computer will not be able to find new updates when they are available. However, we also have expiration built into the app so that people do not stay on outdated versions of Signal.
• We’re open-source software! If you check out this repo and follow the build steps, you can have a desktop client running with code that you have inspected and compiled on your own machine. We have steps for building and pointing to production here: https://github.com/signalapp/Signal-Desktop/blob/master/CONTRIBUTING.md

Software updates are how we provide the latest features, stability fixes, and even security improvements for everybody that runs Signal.

[sneak]

Classifying software updates as Remote Code Execution vulnerabilities is a stretch

That's not what's happening here. Software updates are software updates. Automatic, unattended, no-interaction software updates are RCE, not by a stretch, but by the literal definition of allowing someone to remotely execute code on a system.

Our releases are digitally signed, and signatures are verified prior to any code running on your machine

That's great, but it's not enough, as valid cryptographic signatures can still be coerced. It's still RCE.

We do not automatically run code that is downloaded as part of an update. When an update is available, our client will retrieve it and prompt you to restart to run the latest release.

Yes, you automatically run the update code on Signal relaunch. If it updates while I'm away, and the power goes out and the computer gets turned back on, or the app crashes after replacing its code, or a different user of the system launches the application, the unexamined code runs automatically. R for Remote, C for Code, E for Execution. It's automatic on launch (launch being an event that happens outside of your program).

We’re open-source software! If you check out this repo and follow the build steps, you can have a desktop client running with code that you have inspected and compiled on your own machine.

Irrelevant to the thread; there is no technical measure that ensures that the code that is automatically downloaded and executed automatically on relaunch is open source. The nature of the RCE means that you could sign and publish an entirely proprietary, closed-source update (if you so desired) and the app would run that on next launch.

Look, I trust you people to do the right thing; it's not that I am worried that you are going to push a malicious or proprietary update; it's that the functionality existing that a malicious update can be pushed is inherently dangerous to your entire userbase using the macOS desktop client.

I really don't want to have to start using Signal Desktop in a VM. Please fix this security issue.

[sneak]

I'm not sure why you're defending this so fiercely: it's a violation of user consent to swap out the code when the user doesn't want it changed, and on platforms like iOS where you are prohibited from doing this by platform security measures, the user experience doesn't suffer any for it.

Some of us want our computers (our most important tools) to work on Tuesday in the exact same way they worked on Monday, perhaps contrary to the whims of some remote developer we've never met. That's reasonable, even if it's more convenient for those remote developers to maintain their RCE opportunities.

Developers need to respect the wishes of the owner/operator of the computer that runs their software. User consent is essential, and RCE is asking for a blank check of consent. (Consent does not work that way.)

I cannot offer informed consent to run software I've never seen, which is what this no-interaction update does.

This is a security bug.