Closed sneak closed 2 years ago
sneak
commented
3 years ago 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
commented
3 years ago Which platform is affected by this @sneak ?
sneak
commented
3 years ago I assume it affects all of them, but this was identified on macOS.
Nisc3d
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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:
JanZerebecki
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago Ahh, got it:
Note that both of those buttons mean "run this new software you haven't inspected". Dangerous!
sneak
commented
3 years ago 
"Later" it gets more demanding, too.
jimio-signal
commented
3 years ago Hi!
A few things here:
Software updates are how we provide the latest features, stability fixes, and even security improvements for everybody that runs Signal.
sneak
commented
3 years ago 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
commented
3 years ago 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.
sneak
commented
3 years ago Signal downloaded new, unexamined code to my workstation today, without my consent.
I have to uninstall it until this bug is fixed. Please do not remotely change the code on my computer without my consent.
sneak
commented
3 years ago My temporary workaround for now is to have the Signal.app bundle and all contents owned by a user other than the one that runs Signal, but this is a stupid hack and might not even work (depending on how you do autoupdate). Please fix this.
sneak
commented
3 years ago 
Yesterday, the new update gave me this, because the user running signal desktop doesn't have permissions to alter the app bundle. I hit Cancel.
Today, it's prompting me again, but each time I hit Cancel, it asks again, stuck in a loop. This is a user-hostile bug.
sneak
commented
3 years ago Why is Signal Desktop so intensely aggressive about forcing an update on the Signal release schedule? On iOS, the app is prohibited from modifying itself, and updates must occur via the iOS App Store app update process, and the sky doesn't fall in. Why do you permit Apple to dictate that you can't update arbitrarily, but not the actual owner of the device?!
Nisc3d
commented
3 years ago Block updates.signal.org in your host file or compile the app yourself and stop making up a problem where there isn't one.
lahwran
commented
3 years ago Block updates.signal.org in your host file or compile the app yourself and stop making up a problem where there isn't one.
this is fundamental to the security of any secure software: you need to be able to run a version with a reliable trust chain of verifications from either you or people you trust. the fact that the signal developers feel that they are the only acceptable authorities to trust about whether signal is secure, by nature of managing the update system, is very very concerning to me. it's additionally concerning to me that i don't even see as many commits as i'm getting updates - how do i view change logs of what these updates are delivering to my system? how do i be sure that the signal developers computers have not been compromised to allow an adversary to download malicious code to users of an allegedly secure piece of software with a good reputation, thereby allowing whichever adversary might attempt to do this to bypass signal's security? it's not actually that extreme of a suggestion to wonder if the signal developers themselves are somehow compromised, because signal is trying to be actually secure and is well known, so attackers who would like to monitor communications have strong incentive to attack it. i honestly wouldn't be that shocked to find that signal has been backdoored by an attacker not yet discovered. in order to prevent that from happening or detect it if it has already occurred, we need more insight into the update system and the ability to shut it off. but of course, if the signal developers are sufficiently compromised, they will simply refuse to give that control. that's why it's so critical to pressure them about this.
Nisc3d
commented
3 years ago you need to be able to run a version with a reliable trust chain of verifications from either you or people you trust
If you don't trust the Signal Developers, there is the option to build it yourself, as I said.
it's additionally concerning to me that i don't even see as many commits as i'm getting updates - how do i view change logs of what these updates are delivering to my system
You can see all commits here: https://github.com/signalapp/Signal-Desktop/commits/development Releases are here: https://github.com/signalapp/Signal-Desktop/releases I get updates exactly at the time, there is a new release. I don't know what is different for you. If you want to read what they change look at the code of every commit.
how do i be sure that the signal developers computers have not been compromised to allow an adversary to download malicious code to users of an allegedly secure piece of software with a good reputation, thereby allowing whichever adversary might attempt to do this to bypass signal's security?
Again, you can't be really sure of that. Build it for yourself, if you only trust the code on your machine.
i honestly wouldn't be that shocked to find that signal has been backdoored by an attacker not yet discovered
This is FUD, you can analyze the source code in this repository for yourself and look for the backdoor. Or you can pay someone to do it for you.
we need more insight into the update system and the ability to shut it off
The insight is already there. Look at the Code in this repository and figure out how it works. You can shut it off by blocking updates.signal.org. There isn't a checkbox in the settings for this, because Signal has to keep their Desktop and mobile apps compatible with the server and features on other plattforms. For example if you send a new emoji from iOS to the unupdated Desktop App it will look strange. And more seriously, if you have an old version of Signal Desktop with a bug, that for example increases the CPU load of the server in certain circumstances Signal needs to have a mechanism that will force users to update their Desktop Apps.
I would recommend to lock this thread like the bitwarden guys did, as this is getting ridiculous. I also recommend to read this comment from there: https://github.com/bitwarden/desktop/issues/552#issuecomment-695811829
lahwran
commented
3 years ago fundamental issue i'm interested in solving is making sure that the trust chain is preserved for users who do not want to investigate it deeply. i would also be interested in making sure that these automatic updates i have already gotten only contained code in github. this is an important issue with the entire approach of both of these pieces of software - attempting to offer real security to ordinary users requires a higher level of care than typical applications provide. i understand the startup style approach you're advocating for, but it's not appropriate for something that is intended to provide this level of security to ordinary users. the intense refusal to offer any alternative is in fact concerning - all you're saying by calling it fud, in a fundamental sense, is saying that it is a form of fear, uncertainty, or doubt. fact that those have been weaponized before does not dismiss that they are real things that occasionally show up for real reasons. i don't want to create any more than is actually appropriate - but having an appropriate amount of uncertainty until that uncertainty has been resolved by a technical solution is appropriate for something that needs to stay high-security. i am likely to follow your advice, but i want to ensure that other people who are also using signal automatically get the best security available, which requires me to be able to recommend the main downloads as trustable, which in turn requires signing the updates and verifying that they came from source code that i can build separately. my signal has updated every single time i have closed it in the past week but there have not been that many commits, which again, is not strong evidence of wrongdoing, but does make me somewhat concerned such that i would like proof of non wrongdoing.
i would like input from the signal team about why an update checkbox is not viable even if there is a warning that it may result in running outdated versions that don't work as well; is there any possibility of a change log? links to the github commits that each update is in installing? i do value your development and would love to continue getting it as quickly as possible, i just want a better way to audit it and provide those audits to others as development continues.
Nisc3d
commented
3 years ago my signal has updated every single time i have closed it in the past week but there have not been that many commits, which again, is not strong evidence of wrongdoing
In the last 9 days there were 3 releases if you are running the beta. If not, there was only one release. This looks like a bug to me. By the way you can check what release you are using under Help --> About Signal Desktop.
sneak
commented
3 years ago There isn't a checkbox in the settings for this, because Signal has to keep their Desktop and mobile apps compatible with the server and features on other plattforms. For example if you send a new emoji from iOS to the unupdated Desktop App it will look strange.
@Nisc3d, the iOS app is prevented by the iOS's platform security from updating itself. If the user has disabled automatic app updates in iOS, Signal's iOS client will not update and continue to work (until its embedded timeout/time bomb/expiration). It's important to note that the specific example you used as to why autoupdate is so essential, is, in fact, not an issue at all.
jhermsmeier
commented
3 years ago I just had Signal suddenly pop up without having started it before since booting the machine, and I have not set it to run at startup or anything; A quick look around the logs, and it appears that there was an auto-update going on through ShipIt (from the Squirrel framework), and that there apparently was a launch daemon running in the background which kicked this off.
Now, that update process crashed with an NSInternalInconsistencyException a few times, which then appears to have subsequently caused Signal to be launched (somehow?).
While this particular case seems to be more of a fringe chain of events / bugs, it does take step 1 of 1 out of this issue.
lahwran
commented
3 years ago a thought I've had lately is that a really good solution to this will likely depend on something like cargo crev being developed further, since it's not really like signal is the only thing with this problem. even if signal does expose its updates more clearly, preserving the trust chain properly means that all libraries that it depends on also need to be audited and locked. cargo crev purports to be able to do that now and has promise for reaching legitimately strong trust recommendations with further development, something I'm not actually aware of having been done successfully before. that all said, it still is concerning to have automatic updates that cannot be disabled.
one thing i might suggest to the signal developers is to show an un-dismissible warning when signal is out of date and automatic updates are turned off, which has a button to go into settings where there would be options to either update or enable automatic update rather than a button to update immediately directly on the notification as there is now. potentially this notification could even include an indicator that shows if a vulnerability is known on the current version - in the cargo crev comparison, this is like integrating the functionality of cargo audit. just as important as all of this is making it easy to see what the change logs are on github for every update. that doesn't establish verifiable trust but since signal is supposed to be open-source in the first place it doesn't seem like a huge loss and could promote the code to contributors. it also avoids issues with less technically educated users being unhappy with critical technical changes without understanding them, while still giving anyone who wants it a lead for how to understand the technical changes in detail.
in general, my take is that signal should be distributed using the same standards of security that rustls is, for the same reasons. after all, they are attempting to provide the same security to the same users, despite that those users don't typically know about the inner workings where rustls lives.
sneak
commented
3 years ago I hope that the SolarWinds attack will finally close the debate on the danger of vendor-pushed automatic update once and for all:
For reference and threat estimation, here is another good example of the type of security risk from unattended autoupdate:
It's essential that software not self-modify itself automatically from remote commands.
jimio-signal
commented
2 years ago popping back in here to say that Signal Desktop 5.15 shipped with a preference that allows folks to control automatic updates:
(under Preferences / General)
bumi001
commented
2 years ago @sneak, I am trying to understand you point better. Suppose signal gives you the ability to say no to an update. What would you do after that? What if the update fixes a security vulnerability and you said no? If someone exploits that vulnerability on your system, they can send malicious content to all your signal contacts. Since signal is E2EE, they have no way of knowing what you are sharing.
henricook
commented
2 years ago @sneak, I am trying to understand you point better. Suppose signal gives you the ability to say no to an update. What would you do after that? What if the update fixes a security vulnerability and you said no? If someone exploits that vulnerability on your system, they can send malicious content to all your signal contacts. Since signal is E2EE, they have no way of knowing what you are sharing.
I think the whole point is that it would be his choice to do that. Whereas auto updates offer no choice.
bumi001
commented
2 years ago My point is I am ok with his choice if it only affects him. But, if his choice puts me in danger then I am not ok with that.
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
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.