The attack does not require the attacker to have root on the compromised machine. It does, however, require the page file not to be encrypted, as is common on Linux and Unix systems. The attack I've described requires physical access, e.g. by quickly copying the hard disk. There are special tools and hardware for that. The attacker may need root access on his own system, not the root of the compromised system.
For example, the standard procedure of a law enforcement agency is to confiscate the machine, copy the hard drives, and then investigate the hard drives for forensic evidence, including e.g. checking the page files for master keys if necessary. Of course, your policy could be that a password manager ought not safeguard its users against law enforcement or similar dedicated attackers with physical access (but without tampering the original system, live monitoring with a debugger, etc.). But the reason why good password managers lock the memory is exactly to prevent these kind of attacks. I'm not going into the politics about whether it's good to give ordinary people such strong encryption or not. I merely wanted to point out one weakness of the system. If you as an implementer "argue around" the issue, your potential future users will not necessarily consider this as a good sign. If I were you, I would simply lock the master key in memory to prevent it from being paged out instead. On Monday, October 15, 2018 at 11:05:46 PM UTC+1, robert engels wrote: > > If the user has the ability to read the page file - i.e. root - then he > also has the ability to use the debugger to inspect the live memory as well > - so as the OP pointed out - if root is compromised - nothing is secure. > > On Oct 15, 2018, at 4:36 PM, EricR <ad...@peppermind.com <javascript:>> > wrote: > > If the memory in which the master key resides is not locked, then it may > be written to the page file. An attacker may thus boot the machine from an > external disk, mount the disk, read the page file, obtain the master key > from the page file, and then decrypt the password database. The attack > requires physical access but also works with a cloned disk, so the user > need not even realize it has happened. > > It's a standard attack. It's also not far-fetched to assume that an > attacker could create memory pressure, for example by running a trojan > process as an ordinary that uses as much available memory as possible, in > order to ensure the master key is paged to disk. > > Whether you want to safeguard against this scenario or not is another > question, it always depends on the threat model. I don't know how good this > memguard is, but if it does what it promises, then it would likely make the > application more secure. > > On Monday, October 15, 2018 at 9:18:18 PM UTC, robert engels wrote: >> >> As long as the passwords are not stored in plain text in memory - meaning >> they are only temporarily decoded in order to be provided (and then the >> memory wiped) - there is no difference than the underlying security of the >> file encryption on disk, no ? >> >> > On Oct 15, 2018, at 4:13 PM, Christopher Nielsen <m4dh...@gmail.com> >> wrote: >> > >> > On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt >> > <matthias...@gmail.com> wrote: >> >> >> >> Hi Eric, >> >> >> >> thanks *a lot* for your valuable feedback! I really appreciate it. See >> comments inline: >> >> >> >> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR: >> >>> >> >>> Since you're looking for opinions on the security concept, two >> questions spring immediately to my mind: >> >>> >> >>> 1. Does the daemon keep the sensitive data in locked memory that >> cannot be paged out? If so, how cross-platform is this? >> >> >> >> >> >> No it doesn't. As of now i consider the root-user a good guy ;-) >> >> He's the only one who could access the pagefiles anyway. >> >> >> >> So is this really an issue? If yes i could use this cross-platform >> solution to pin the key: >> >> >> >> https://github.com/awnumar/memguard >> >> >> >> >> >>> >> >>> >> >>> 2. How does the client communicate securely with the daemon? Which >> encryption protocol/handshake is used for this? (If it just uses a socket, >> what would prevent another process from reading out the master password?) >> >> >> >> >> >> >> It's in fact a unix domain socket file which is only accessible for >> the owner of the key. ( Thanks for bringing this up, i forgot to flag the >> file correctly - it's now fixed). >> >> Relying on the file permissions in unix shouldn't be a problem, right? >> >> >> >> >> cheers & again - many thanks, >> >> >> >> Matthias >> > >> > You seem to be putting a lot of trust in facilities that are trivially >> > exploitable to a determined attacker. For software like a password >> > manager, assuming the kernel is secure is a poor security model. In >> > addition to the existing attack surface, we live in a world where >> > side-channel attacks are becoming more common, e.g., Spectre and >> > Meltdown, so it isn't safe to assume the kernel or hardware are >> > secure. A password manager needs to have a robust security model that >> > has a minimal trust model if it is to be more than a toy. >> > >> > Just my $0.02 >> > >> > -- >> > Christopher Nielsen >> > "They who can give up essential liberty for temporary safety, deserve >> > neither liberty nor safety." --Benjamin Franklin >> > "The tree of liberty must be refreshed from time to time with the >> > blood of patriots & tyrants." --Thomas Jefferson >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "golang-nuts" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to golang-nuts...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
