They don’t need physical access (hold the device in their hand), they just need a command execution, which is a much lower bar. I expect some defence in depth for an application that holds some of the most private information there is about me.
Comment on Signal downplays encryption key flaw, fixes it after X drama
quantumcog@sh.itjust.works 2 months ago
I understand Signal’s stance on this. For this vulnerability, the attacker needs physical access to computer. If the attacker has already gained physical access, the attacker can already access your messages, crypto wallets, password managers. Many password managers also have this flaw. For example, Someone can change Keepass master password if the user is already logged in to the session, if they have physical access to the PC and lock you out of all your accounts.
uiiiq@lemm.ee 2 months ago
quantumcog@sh.itjust.works 2 months ago
The argument still holds. If they have remote execution access, they already have your data. Encryption can’t protect your data here because encrypted data will automatically become unencrypted once the user logs in.
ooterness@lemmy.world 2 months ago
No, defense in depth is still important.
It’s true that full-disk encryption is useless against remote execution attacks, because the attacker is already inside that boundary. (i.e., As you say, the OS will helpfully decrypt the file for the attacker.)
However, it’s still useful to have finer-grained encryption of specific files. (Preferably in addition to full-disk encryption, which remains useful against other attack vectors.) i.e., Prompt the user for a password when the program starts, decrypt the data, and hold it in RAM that’s only accessible to that running process. This is more secure because the attacker must compromise additional barriers. Remote execution with root is harder than remote execution in general.
sudneo@lemm.ee 2 months ago
You don’t need root (dump memory). You need the user password or to control the binary. Both of them relatively easy if you have user access. For example, change ENV variable to point to a patched binary first, spoof the password prompt, and then continue execution as the normal binary does.
douglasg14b@lemmy.world 2 months ago
They don’t necessarily need RCE access.
Also this isn’t how security works. Please refer to the Swiss cheese model.
Unless you can guarantee that every application ever installed on every computer will always be secure under every circumstances then you’re already breaking your security model.
An application may expose a vulnerable web server which may allow read only file system access without exposing the user to any direct control of their computer from an attacker.
This is just one of many easy examples that are counter to your argument here.
sugar_in_your_tea@sh.itjust.works 2 months ago
Exactly. They just need to be able to send a file somewhere, and there are other attacks where they can do what w/o code execution.
partial_accumen@lemmy.world 2 months ago
For example, Someone can change Keepass master password if the user is already logged in to the session, if they have physical access to the PC and lock you out of all your accounts.
This seems like easy fix is available. On Windows, Access Shadow copies, restore previous version from $DayBeforeLockout. Or on Linux, specific file systems have automatic volume level snapshotting available. Or on either…restore the keepass file from a backup before the change.
quantumcog@sh.itjust.works 2 months ago
Yeah, I know about this. That’s why backups are so important.
thurstylark@lemm.ee 2 months ago
Yeah, this is why I added a hardware key to my db. The hardware key is required not just for reading the db, but writing to it as well.
Another tip: use something like an OnlyKey that has its own locking and self-destruct mechanisms so this method isn’t foiled by simply acquiring the key.