How Does Strongbox Perform Against RAM Dumps or Memory/Debugging Attacks?

The threat of someone being able to access the memory of a running instance of a program is a notoriously difficult one to protect against. This is particularly acute for password managers which, at the end of the day, are also just programs too. This is one of the reasons platforms (e.g. iOS, MacOS, Linux, Windows) make huge efforts (e.g. ASLR, NSFileProtectionComplete, permissions, etc) to prevent attackers from gaining this kind of privileged access. To gain this kind of privilege, attackers usually have to resort to exploiting some kind of flaw in the underlying OS.

Historical and Contemporary Threats

In the KeePass world, there's a bit of a history of developers and their apps doing some really cool and smart things, and going the extra mile to try to fade this threat. Consider the original KeePass app on Windows. The developer came across problems trying to do tackle memory attacks and wrote about it (see 1 and 2). Also see the last paragraph of the KeePass memory protection section here. Similarly the KeePassXC developers struggle with it too. There's a broader analysis here of 1Password, LastPass, and Dashlane which all suffer in one way or another from someone being able to dump their process memory (there's a good KeePass related question here too). The existence of programs like KeeFarce and KeeThief, squarely aimed at KeePass shows that there is no easy defence against this threat.

Bottom Line

The bottom line is that if someone serious/sophisticated has access to your unlocked device with your password manager running and your database unlocked, it may, indeed it almost certainly is, already game over. If we consider running on a platform like iOS, this would require a device be "jailbroken" or the existence of some other (probably zero-day) exploit. In most cases, someone who is able to perform a memory dump, probably doesn't even need to do it. There are other options for attackers with this level of access. They can probably just have the application itself execute code to directly decrypt any secrets they like. Alternatively they might surreptitiously install a key-logger, if deniability is important. Another option is to simply dump out the database, rather than try steal database credentials. If your password manager must hold your unprotected/obfuscated database credentials in memory at some point (and it's hard to imagine any way around this) then someone with this level of access will be able to view/dump it.

What's your Threat Model?

This kind of actor is fairly advanced and determined and so what one should really consider, if this is a serious concern rather than just an intellectual curiosity, is one's threat model. Who are you trying to protect your secrets against? Do they involve some very determined (possibly state-level adversaries?) If so, you are probably fairly sophisticated yourself, and you definitely do not want to be entering your master password on a compromised device. As always, XKCD illustrates the point with humour. It's really important to have a rough idea of what you're trying to protect against, and then work from there, accept that there's always a security/convenience trade-off, and find one that you're comfortable with.

Some Technical Details on Hardening Techniques
Memory "Scrubbing"

One technique used by developers is to zero out (or alternatively randomise) any sensitive memory before deallocating it. This is a good idea, but in unmanaged languages (or indeed ARC on the Apple platforms), memory leaks (especially small ones) are very common, so one has to make sure sensitive secrets are not held/referenced beyond their required lifespan. For managed languages (e.g. garbage collected languages like Java or C#) the problem could be compounded by the difficulty of determining when the GC will sweep through.

Obfuscating In-Memory Secrets

Another technique involves "obfuscating" in-memory secrets, a technique that scrambles or conceals secrets from a casual prying observer, but won't stand up to a determined attacker. It can be considered as being "like" encryption, but the encryption key is likely lying around, not too far away... e.g. "The door is locked but the key is under the doormat", to take a real world example. Again, perhaps worth implementing, but won't survive a sustained attacker.

UI Libraries Keeping Un-Obfuscated Secrets Around

Another issue arises, in part due to (almost) unavoidable modern development practices, and that is that most Apps use third party or system provided UI (or other) libraries which are not specifically hardened against a memory attacker. Consider the text field where you enter your database password, this is likely to be a system provided UI control, and these controls will have their own memory management and buffering state, and will not be hardened. The original KeePass developer came across this (see above). This is very difficult to workaround, perhaps building your own controls from scratch, an extremely demanding job and hard to get right.

Ongoing Strongbox Hardening & Summary

Strongbox is making efforts to improve and harden its memory usage. Unfortunately, an attacker with this level of access to your process is will prove to be very difficult to protect against. We provide some further reading below for those interested.

Further Reading & Resources