Email or username:

Password:

Forgot your password?
Meredith Whittaker

There’s been some chatter about Signal desktop recently, so let’s clear the air. Three points:

1. The reported issues rely on an attacker already having *full access to your device* — either physically, through a malware compromise, or via a malicious application running on the same device. This is not something that Signal, or any other app, can fully protect against. Nor do we ever claim to.

54 comments
Meredith Whittaker

2. We continue working to harden our desktop build across supported operating systems and take advantage of new platform capabilities as they emerge. Those of you following our repo can follow this work there.

3. The posters who raised this issue did so without contacting us directly. Instead, they went straight to social media, in some cases using inflammatory language. And they dropped these claims over a US holiday weekend. This is the opposite of responsible disclosure.

Meredith Whittaker

We ask those who are serious about security and privacy to please engage us directly in the future, instead of resorting first to online claims that can confuse non-experts and lead people to make unsafe choices and develop inaccurate mental models based on scary language. We monitor security@signal.org carefully and respond to all legitimate reports.

Talya (she/her) 🏳️‍⚧️

@Mer__edith as always, these people act in bad faith, and as always, the only thing they get is making people less secure. heck, this whole thing was already discussed a year and a half ago after the bogus CVEs filed by johnjhacking. but of couse the ones spreading this never bother to check if this has already been discussed before, since they only want attention.

Khürt Williams

@Mer__edith Certain types of people want to be influencers. I think a better word to describe them is infamous.

Bas (Tools on Tech) :verified:

@Mer__edith After reading "trust me I'm lying" asking for this feels like asking water to not be wet. Anyone that knows security would realize that an exploit that requires full system access isn't really an exploit but non-news. So it feels like emotional click farming, with no regards whatsoever for actual fact checking.

David

@toolsontech @Mer__edith The real issue here is the forward access (session cloning), which seems like a pretty big issue. Momentary access to a system (not necessarily “full” access) can get someone the info needed to silently clone a session, intercept future messages, and impersonate the victim.

S1m

@Mer__edith Is it possible to add this address to the footer of signal.org or create a security.txt ? One have to go through the FAQ to find out this email address

0x00

@S1m @Mer__edith It looks like security.txt was already added at the beginning of the month

signal.org/.well-known/securit

DELETED

@Mer__edith

Non-Expert here. Love using Signal with my closest peeps for quality & to avoid data scraping... We understand cyber security is constantly evolving. We also understand in light of recent news everywhere, at any time someone else could be reading everything on our screen and certainly our desktops are vulnerable even with good software protecting us.
If we wanted to say something that could be used against us, we would meet at the beach in swim wear. Glad we don't need to do that.

London Eastfield 🇵🇸

@UrNotTheBossOfUs @Mer__edith

"at any time someone else could be reading everything on our screen and certainly our desktops"

Huh? Who are "someone else", and how can they access your computers?

DELETED

@LawmanLungis @Mer__edith
Sorry, got the chores done.
Want to see something scary, look up Pegasus Spyware. It's old news from several years ago. Imagine how advanced now and a hell of a lot less expensive for law enforcement.
Most people would be shocked to know what local LE capabilities are today.
Tech companies float the idea of screenshots nonstop so they can feed AI. Public asks governments to block that shit.
IMO it's already going on long time before we read about it.
Also, hackers.

Mysk🇨🇦🇩🇪

@Mer__edith

Hi Meredith, let me address your points:

1) The issue we highlighted does not require “full” access to the device. Signal desktop stores the chat database in an unprotected area of the file system that’s accessible by any user process. This would allow any program without any special permissions or user prompts to access the database in full. This can be solved by sandboxing, which relies on the OS to prevent any process from accessing data within the sandbox.

… 🧵 1/4

Mysk🇨🇦🇩🇪

@Mer__edith

2/4

2) The issue was reported to Signal by others back in 2018, so we didn’t find anything new. App sandboxing technology had been available for a long time on desktop (Windows AppContainer and macOS App Sandbox). Even if we ignore sandboxing, while Signal encrypts the chat database, it stores the encryption key insecurely in plaintext.

… 🧵

Mysk🇨🇦🇩🇪

@Mer__edith

3/4

3) We “the posters” didn’t feel the need to reach out to Signal first since the issue had been known to Signal’s developers since 2018. After 6 years without a resolution, we believe it becomes more important to raise awareness than to attempt to directly engage with Signal, or any other vendor. Also, I challenge you to point out any instance of inflammatory language in our posts about Signal.

…🧵

Mysk🇨🇦🇩🇪

@Mer__edith

4/4

Finally, Signal has a huge responsibility towards your users, many of whom rely on Signal to be the most secure way of communicating in areas of the world where their lives would be in danger if their messages were to be compromised. This is not hyperbole, and Signal needs to continue to live up to that responsibility.

DELETED

@mysk @Mer__edith

All I can say as a user who relies on Signal a lot and is one of few who actually supports Signal by monthly donations through its app is this:

The expectation from the paragon of private and secure messaging platform is that it is indeed fully private and secure to a point where even physical access (short of knowing admin credentials), Signal must be made to ensure of anything within it is encrypted, including pictures and documents that may be shared.

DELETED

@mysk @Mer__edith

I love Signal and will continue to use and support and recommend it but it’s things like this that slowly begin to leave a bad taste in your mouth.

I hope this is resolved soon. By the looks of it, it can be as it’s a technical issue and we don’t seem to be limited by technology unless my interpretation and inference from all that I have read is incorrect.

Please look into this more and share an update with a fool proof resolution for the millions relying on it.

Compuguy, Lover of Cats 😸😼

@mysk
@Mer__edith This should be a concern. But one should factor in if a malicious actor has full access to the computer, you're pretty much 💩 out of luck. This doesn't mean that @signalapp couldn't implement a pin/password lock & encryption to the desktop app to make it harder for someone to access that information....

ChiefBongo

@mysk plus Desktop Systems are a lot more vulnerable and susceptible to malware than Mobile OS's, especially Windows. I have always been wary of using Messenger Apps on Desktop - rightfully so, it turns out.

DELETED

@Mer__edith Most of these people are probably serious about attacking Signal for various reasons and not serious about security and privacy. "Experts" who in order to criticize a piece of software pull the OS-security card are not experts at all or have ill intentions to begin with.

Draken BlackKnight

@Mer__edith
Seems like the only difference between "Mysk" and "Musk" is one letter off.

Cameron Otsuka

@Mer__edith This was reported back in 2018 which was closed as “won’t fix” redirecting to this from 2015.

Sapient

@Mer__edith Wasnt this first disclosed in 2018?

bleepingcomputer.com/news/secu

Seems like its been on the back burner for a while and just recently resurfaced.

erebion

@Mer__edith Why is Signal desktop based on Electron, which is basically an outdated Chrome/Chromium browser that does not follow widely acctepted Linux standards and makes it hard to package for distributions as well as making it harder to make this "secure" instead of using literally anything else? 🤔

I like the approach of the alternative client Flare a lot. It's got a clean interface and it's not a browser.

Fabrice Desré

@erebion @Mer__edith Signal is currently using Electron 31.x (github.com/signalapp/Signal-De) which is itself tracking current chromium (128.x). I'm not an Electron fan either, but that doesn't mean it's ok to spread fake info.

Hugo 雨果

@Mer__edith I am deeply worried by how you are trying to misrepresent and distort this situation. Your words are damaging my trust in Signal a lot more than the actual security issue at hand.

You claim that the attack "requires full access" (it only requires read-only access), that it cannot be avoided (other messaging clients protect against this particular scenario), and that is was disclosed irresponsibly (the issue was mentioned and circulated on twitter a year or two ago).

jntesteves

@whynothugo @Mer__edith There is no such thing as read-only access to a computer. To read and exfiltrate data, you must have control of the machine. Control is full access, the terms are used interchangeably.

Hugo 雨果

@jntesteves An attacker might have access to backups, or might be able to run code as an unprivileged user. These two (and countless others) scenarios grant an attacker read data without being even close to "full access".

gregor herrmann

@Mer__edith "US holiday weekend"? sorry to say, but such a thing is irrelevant to ~95% of the world popoluation.

Lien Rag

@Mer__edith

Thanks for your reaction.
If I'm not mistaken, it's not "full access" that is required though (i.e., no root password is necessary to access the sqlite database and the password).
Leaving such a sensitive information accessible to *any* process is sloppy.

MaybeMyMonkeys

@lienrag @Mer__edith if a machine is compromised, all you need to do is screen captures at short intervals to get a lot of useful information. Not passwords required.

vascorsd

@MaybeMyMonkeys @lienrag @Mer__edith it literally doesn't matter. At the point that something is actively detecting that signal is installed and trying to get data in the machine it can do anything. Screenshots, keylogger, access files, intercept the network, etc. It's basically not possible to have Signal app installed and running in windows in a way that doesn't allow malicious things running from getting wtv it wants. The whole thing is blown out of proportion.

Don't use it on windows.

Tio
What's the context here? I've not heard of this.
Guillaume Ross

@Mer__edith Since mobile OSes have much stronger sandboxing, and Signal on desktop OSes will always be more likely vulnerable to malware, would you consider at least indicating that I’m talking to someone that has Signal on PC vs not?

Hugo 雨果

@Mer__edith The scenario that has been mentioned lately is "an attacker with temporary read-only access to the filesystem can copy session data and hijack the session indefinitely without any indication".

This CAN be mitigated, and plenty of other messaging applications have done so for many years. The most obvious solution to this particular problem is using the platform-specific keyring to store the session token so that it is encrypted at rest.

Hugo 雨果

@Mer__edith

I want to make it clear that it is theoretically possible to prevent this attack, that many other messaging clients prevent against it, and even alternative clients to Signal's network prevent it.

Flare (an alternative Signal client) DOES protect against this specific attack: gitlab.com/Schmiddiii/flare/

Your claims of "This is not something that Signal [...] can protect against" is complete BS.

Jez Caudle 🐡♦️on🛤️

@whynothugo @Mer__edith The quote you’ve cut short is:

The reported issues rely on an attacker already having *full access to your device* — either physically, through a malware compromise, or via a malicious application running on the same device. This is not something that Signal, or any other app, can fully protect against. Nor do we ever claim to.

I understand that to mean that Signal can not stop an attacker taking over your system. Which is true.

The rest of the thread mentions that Signal are looking at implementing at-rest mitigations.

Should Signal have done this from the start? Yes, I believe they should. And criticism that they didn’t is also valid.

Raising a PR that fixes the issue would have been even better.

@whynothugo @Mer__edith The quote you’ve cut short is:

The reported issues rely on an attacker already having *full access to your device* — either physically, through a malware compromise, or via a malicious application running on the same device. This is not something that Signal, or any other app, can fully protect against. Nor do we ever claim to.

Hugo 雨果

@JezCaudle @Mer__edith This attack **does not** require an attacker to have unrestricted access to the device, it only requires a one-time read-only access.

Erica Marigold :vm:

@Mer__edith Well, the logic doesn't make sense as to why you encrypt local messages but not media then, does it?

AlexTECPlayz

@Mer__edith Yeah no, this post is a big miss and reeks of sh*t. Just because OSes already have disk encryption that can be enabled, doesn't mean Signal shouldn't also at the very least, give the option to also encrypt the files that are saved/cached/whatever.

Maybe some missed the option to encrypt their system and can't be arsed to reflash their entire OS again - like me, I didn't see any option in the Debian installer to encrypt the disk or the home folder, and forgot about it, so now I'm currently not in the mood to literally reinstall the system again to manually encrypt it.

I know very well that this is risky if someone had access to the hardware, but I would have felt better if Signal Desktop was also encrypting the files.

I stopped using Signal, mostly due to its centralised manner, and the phone number requirement, and this issue that apparently has been known for years and not getting fixed, is certainly not pushing me to use Signal again. Do better.

@Mer__edith Yeah no, this post is a big miss and reeks of sh*t. Just because OSes already have disk encryption that can be enabled, doesn't mean Signal shouldn't also at the very least, give the option to also encrypt the files that are saved/cached/whatever.

Maybe some missed the option to encrypt their system and can't be arsed to reflash their entire OS again - like me, I didn't see any option in the Debian installer to encrypt the disk or the home folder, and forgot about it, so now I'm currently...

AlexTECPlayz

@Mer__edith I mean, look at Molly, a fork of Signal on Android that also encrypts the shared preferences XML file, while regular Signal does not.

Signal is both a security and privacy-focused instant messenger. It should encrypt even banal things such as preferences, and shared images, video, media. You're clearly not out of options, and you should provide the encryption for the attachments, because from reading the comments here, it's very much possible.

(github.com/mollyim/mollyim-and)

@Mer__edith I mean, look at Molly, a fork of Signal on Android that also encrypts the shared preferences XML file, while regular Signal does not.

Signal is both a security and privacy-focused instant messenger. It should encrypt even banal things such as preferences, and shared images, video, media. You're clearly not out of options, and you should provide the encryption for the attachments, because from reading the comments here, it's very much possible.

"How Local Encryption Works

Database

Signal uses an SQLCipher database to store contacts, chat history, and attachments, in the app-specific directory of the device. The database is encrypted with AES 256-bit keys randomly generated the first time the app is run.

The encryption key is wrapped with Android KeyStore and stored in the Shared Preferences. If the KeyStore is unavailable as in Android 5.1 (Lollipop) and previous, the key is written as-is to the Shared Preferences.

In Signal, Shared Preferences are plaintext XML files stored along with the database.

However, Molly protects the Shared Preferences with the user's passphrase, providing full encryption of data at rest regardless of the way Android may or may not be encrypting its own storage.
Shared Preferences

Molly encrypts preferences value using AES-256 CBC mode. The preference name and the encrypted value are hashed together with HMAC-SHA256, and stored together with the encrypted value, providing authenticated encryption for the preferences.

The Shared Preferences encryption key is protected with the passphrase set in Molly, run through Argon2id (KDF) with a random salt. The CPU and memory cost parameters of the KDF algorithm are calibrated so that one attempt takes approximately 3 seconds. The passphrase is wiped from memory after hashing it.

To discourage brute-force passphrase attacks, starting in Android 6.0, the output of Argon2 is entangled with 256-bit MAC keys tied to the Android KeyStore."
Meta

@alextecplayz
Note that you can in fact encrypt your home without reinstalling - see e.g. techblog.dev/posts/2022/03/enc

But I do suggest that you think about how you voice critic. It doesn't sound very grateful, especially considering what Signal is doing for humanity.
@Mer__edith

AlexTECPlayz

@metacolon I know I can encrypt my /home even after installing the system, but that would be slow and data could be at risk of being corrupted or erased if it goes wrong, it's just not something I want to do now, I'll do it someday, and I'll go all in. The performance impact isn't that big nowadays, even on hard drives, even with FDE.

As for voicing my criticism - I'm not trying to sound grateful OR ungrateful.

What Signal is doing is nice, they are definitely helping out people in countries where censorship is front and center.

But at the same time, you WOULD expect a project that is literally focused on a secure and private instant messenger, to not ignore a glaring issue that was known since 2016 (or 2018), because it is a big issue nonetheless.

Meredith's statement was thoroughly disappointing, though, considering it's a blatant lie when they say the issue can't be fixed.

@metacolon I know I can encrypt my /home even after installing the system, but that would be slow and data could be at risk of being corrupted or erased if it goes wrong, it's just not something I want to do now, I'll do it someday, and I'll go all in. The performance impact isn't that big nowadays, even on hard drives, even with FDE.

AlexTECPlayz

@metacolon "The reported issues rely on an attacker already having *full access to your device* — either physically, through a malware compromise, or via a malicious application running on the same device. This is not something that Signal, or any other app, can fully protect against. Nor do we ever claim to."

But Signal can take steps against this happening, by literally encrypting the attachments, this is possible, and we know it is, because many other programs have done it already. It's a basic feature Signal refuse(d)s to implement.

"The posters who raised this issue did so without contacting us directly. Instead, they went straight to social media, in some cases using inflammatory language. And they dropped these claims over a US holiday weekend. This is the opposite of responsible disclosure."

This is in bad faith. The issue was KNOWN for years, it was only brought back to light. Mysk doesn't need to contact Signal to talk about this issue, it's not something new.

@metacolon "The reported issues rely on an attacker already having *full access to your device* — either physically, through a malware compromise, or via a malicious application running on the same device. This is not something that Signal, or any other app, can fully protect against. Nor do we ever claim to."

AlexTECPlayz

@metacolon Here are the GitHub issues. It goes as far back as December 2015.

github.com/signalapp/Signal-De

github.com/signalapp/Signal-De

And yet Signal closes both issues as 'Won't Fix', because apparently, people who don't have disk encryption (due to a multitude of possible reasons) can get fucked. The point of a security and privacy-focused project is to try and reclaim/secure as much as possible. What if someone is using Signal Desktop on a work computer, that CANNOT have disk encryption, for some reason? What if someone is using Signal Desktop on a public cafe computer, that doesn't have disk encryption?

Signal must account for all possibilities, and offer the option to enable data encryption at rest. I'm not trying to shit on Signal, but I'm not blind to suck them off and call everyone that criticizes Signal 'ungrateful'. I'm not specifically calling you out, just users in general, because I see a lot of people evangelizing Signal, on the same level as they evangelize Linux or Torvalds.

@metacolon Here are the GitHub issues. It goes as far back as December 2015.

github.com/signalapp/Signal-De

github.com/signalapp/Signal-De

And yet Signal closes both issues as 'Won't Fix', because apparently, people who don't have disk encryption (due to a multitude of possible reasons) can get fucked. The point of a security and privacy-focused project is to try and reclaim/secure as much as possible. What if someone is using...

Meta

@alextecplayz
The issues you linked are about Signal storing stuff unencrypted. The only real new issue that came up with mysk imo is that you can clone a session. That's not in the issues and should have been a responsible disclosure.

Providing the option for a custom encryption password is something Signal *should* do. It's the same for mobile, which is why I'm using Molly. But it's not something they *must* do, as you imply. It's a valid feature request, not a bug.

The only thing Meredith said is impossible is to protect against full system access. I agree that it's a bit mialeading, but it is reasonable to assume that if someone can read your files, they can also read your screen. And Signal can't protect against that.

@alextecplayz
The issues you linked are about Signal storing stuff unencrypted. The only real new issue that came up with mysk imo is that you can clone a session. That's not in the issues and should have been a responsible disclosure.

Providing the option for a custom encryption password is something Signal *should* do. It's the same for mobile, which is why I'm using Molly. But it's not something they *must* do, as you imply. It's a valid feature request, not a bug.

AlexTECPlayz

@metacolon Okay, the cloning session thing might be new, I haven't looked up on that. But I'm mostly talking about the attachment encryption issue here.

Yes, it's not something that Signal must do, but they should, considering they're always up talking about how privacy and security are so important. It's not a good look for a project dedicated to this, to ignore such a feature.

Apparently they did the data encryption at-rest for Signal on Android (before it was removed? and added back? by Molly) because Android didn't have "usable" FDE at the time.

And, come on, if WhatsApp has data encryption at-rest, I think it would be almost necessary for Signal to have it too, just because WA would be superior in this specific regard otherwise.

" but it is reasonable to assume that if someone can read your files, they can also read your screen" - this would depend on the OS. Linux has Wayland to prevent this, Android allows apps to prevent screen captures (screenshots would be blacked out).

@metacolon Okay, the cloning session thing might be new, I haven't looked up on that. But I'm mostly talking about the attachment encryption issue here.

Yes, it's not something that Signal must do, but they should, considering they're always up talking about how privacy and security are so important. It's not a good look for a project dedicated to this, to ignore such a feature.

blastoise

@Mer__edith This is a lie. You should honestly accept Signal took no action to fix a vulnerability reported 6 years ago.

Go Up