Exactly, which is why your drives should be encrypted.
Once you lose physical control of a device, all bets are off, drive encryption at least slows down attackers significantly.
I have far more sensitive, and a greater volume of data, on the drive than just comms.
Sethayy@sh.itjust.works
on 08 Jul 2024 16:57
collapse
Drive encryption wouldn’t do anything to mitigate this though? A process running on your PC needs access to your drive, and so with the current setup you have either the option to trust 100% every software with your signal encryption keys, or to simply not use them.
Seems like a pretty big security flaw that we have actual solutions to.
You could maybe form a hackey way to allow only the signal process to an encrypted FUSE filesystem that decrypts its own keys on the fly, but again there’s already ways to do this in software that isn’t like using a wrench to plug a leak. (and this setup would just have it’s own set of keys that need to be protected now, probably by a traditional method like kwallet)
douglasg14b@programming.dev
on 08 Jul 2024 18:07
nextcollapse
I mean… Every serious operating system already has some form of keyring feature right?
Sethayy@sh.itjust.works
on 08 Jul 2024 18:12
collapse
Ie. what signal should be using, yet isnt
sun_is_ra@sh.itjust.works
on 08 Jul 2024 23:59
collapse
there is SELinux which give more fine tuned permissions for each app but it was too complicated for me
Sethayy@sh.itjust.works
on 09 Jul 2024 13:17
collapse
And if you’re using SELinux as a kwallet/keyring replacement, you’re using it wrong (but again security in layers doesn’t stop you from using both)
douglasg14b@programming.dev
on 08 Jul 2024 18:04
collapse
Not necessarily. There are many paths to exfiltrated data that don’t require privileged access, and can be exploited through vulnerabilities in other applications.
punkcoder@lemmy.world
on 08 Jul 2024 12:28
collapse
I think the issue that they are trying to make is that there are modern ways of protecting the keys with hardware level security, that aren’t being used. As someone who works in AppSec this is all too common. All it takes is one library in an application to be popped (doesn’t have to be signal), and security keys end up leaked. If it isn’t already, I’m sure that signals keys will be included in exfil scripts.
Tools like TPM and SecureEnclaves (TrustZone,etc) mean that malware, and other nasties have a higher bar that they need to meet.
douglasg14b@programming.dev
on 08 Jul 2024 18:04
collapse
Yeah, and electron already has a secureStorage API that handles the OS interop for you. Which signal isn’t using, and a PR already exists to enable…
punkcoder@lemmy.world
on 08 Jul 2024 19:11
collapse
I’m not surprised… I think people (‘the ones that care at least’) would be horrified to know how much of this stuff slips through, because it’s hard (there are so many other things that are pulling at developers that something falls through the cracks). Most of the time the right answer is to bring it up. Then thank them when they resolve the issue (with beer and pizza money at the very least).
threaded - newest
Don’t the keys have to be in plaintext at some point so they can be used
Yeah but they don’t have to be visible to every process the user runs, my Minecraft mods really don’t need access to my encryption keys
They could at least allow for setting paaword. Then your keys are encrypted with that password
Ah yes, the old “your data isn’t safe when an attacker has full access to your pc account” vulnerability
Yeah fuck security in layers, my first layer is 100% bulletproof so I got no reason to worry
Exactly, which is why your drives should be encrypted.
Once you lose physical control of a device, all bets are off, drive encryption at least slows down attackers significantly.
I have far more sensitive, and a greater volume of data, on the drive than just comms.
Drive encryption wouldn’t do anything to mitigate this though? A process running on your PC needs access to your drive, and so with the current setup you have either the option to trust 100% every software with your signal encryption keys, or to simply not use them.
Seems like a pretty big security flaw that we have actual solutions to.
You could maybe form a hackey way to allow only the signal process to an encrypted FUSE filesystem that decrypts its own keys on the fly, but again there’s already ways to do this in software that isn’t like using a wrench to plug a leak. (and this setup would just have it’s own set of keys that need to be protected now, probably by a traditional method like kwallet)
I mean… Every serious operating system already has some form of keyring feature right?
Ie. what signal should be using, yet isnt
there is SELinux which give more fine tuned permissions for each app but it was too complicated for me
And if you’re using SELinux as a kwallet/keyring replacement, you’re using it wrong (but again security in layers doesn’t stop you from using both)
Not necessarily. There are many paths to exfiltrated data that don’t require privileged access, and can be exploited through vulnerabilities in other applications.
I think the issue that they are trying to make is that there are modern ways of protecting the keys with hardware level security, that aren’t being used. As someone who works in AppSec this is all too common. All it takes is one library in an application to be popped (doesn’t have to be signal), and security keys end up leaked. If it isn’t already, I’m sure that signals keys will be included in exfil scripts.
Tools like TPM and SecureEnclaves (TrustZone,etc) mean that malware, and other nasties have a higher bar that they need to meet.
Yeah, and electron already has a
secureStorageAPI that handles the OS interop for you. Which signal isn’t using, and a PR already exists to enable…I’m not surprised… I think people (‘the ones that care at least’) would be horrified to know how much of this stuff slips through, because it’s hard (there are so many other things that are pulling at developers that something falls through the cracks). Most of the time the right answer is to bring it up. Then thank them when they resolve the issue (with beer and pizza money at the very least).
Looks like it’s waiting for approval, github.com/signalapp/Signal-Desktop/pull/6933 for anyone else thats interested.