Security Issue: No verification required after copying %AppData%\Signal to another device

[daixtrose]

Using a supported version?

• I have searched searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

When migrating from one Windows OS to another it suffices to copy %AppData%\Signal (which normally expands to C:\Users\<username>\AppData\Roaming\Signal) to the new target OS. Signal seems not to check the access token against a device signature or fingerprint and hence does not request access validation or linking of the new device. I consider this a security issue. Anyone who can extract the %AppData% directory from a computer can silently follow any communication of the attacked person(s).

Steps to reproduce

• Log into a Windows 10 or Windows 11 operating system
• Make sure, the Signal Desktop app starts and that you can read messages
• Copy the directory %AppData%\Signal to a USB stick or a share
• Log into another Windows 10 or Windows 11 operating system
• Copy the directory Signal from the USB stick or share into the directory %AppData%
• Start the Signal Desktop app
• Send a message to a contact

Expected result

Signal Desktop App cross-checks if the stored access token (or whatever Signal uses here) was originally stored on the very same machine by using a robust device fingerprinting mechanism and in case of a deviation treats the current device as if it has to linked again.

Actual result

• Signal does not request entering the user credentials.
• In the mobile Signal app the list of linked devices only shows the original device from which %AppData% was copied. This is my main concern.

Screenshots

No response

Signal version

6.44.0 production

Operating system

Windows 10 or Windows 11

Version of Signal on your phone

6.54.0.8

Link to debug log

No response

[cherti]

Anyone who can extract the %AppData% directory from a computer can silently follow any communication of the attacked person(s).

Is this actually the case? because if the client is continued to be used, they should have the same keys, so both installations would share the server-queue, meaning all messages that arrive on one do not arrive anymore on the other because they are considered delivered. Not necessarily immediately obvious, but certainly not silent, unless I'm missing something here?

Aside from the fact that security issues starting with "if the attacker has full disk access" are generally difficult to impossible to defend against. At that point, there could be keyloggers deployed or the data in the app folder/the Signal installation used could simply be modified to disregard the fingerprinting mechanism alltogether, because why would an attacker be doing this and then not go the extra mile to just patch that protection out on their own client? The data and the keys are there, after all.

So requiring the fingerprinting mechanism here seems to be an approach that would realistically only hit legitimate users, but would not constitute a reliable (if any) defense against a malicious actor?

[jamiebuilds-signal]

This isn't a security issue in Signal Desktop. As an application that runs on top of the base operating system layer, Signal cannot mitigate OS-level vulnerabilities or the complete compromise of your computer.

If someone has obtained access to your computer and is able to extract arbitrary files from the filesystem, they can indeed use that extraordinary level of access to do anything on your computer (or another computer) with the same level of access as you. It wouldn't be appropriate for a privacy-focused application like Signal to implement a form of DRM that profiled and collected detailed hardware information, nor would it be appropriate to upload a function of that hardware profile to a remote service. The Signal service is specifically designed to store as little information as possible.

The proposed approach likely wouldn't work under real-world conditions anyway, because any hypothetical attacker with the necessary level of unauthorized access to extract arbitrary files from a compromised device also likely has the ability to see all of the hardware on the compromised system. That attacker could then simply steal the authentication credentials and send a matching device fingerprint — either by mimicking the hardware or by compiling a custom client that simply reported the expected value to the service.

We don't use GitHub issues as a platform for discussions, but we encourage you to post on the community forum if you would like to continue the conversation there. Thanks for sharing your ideas!