Keepassxc: SecurityEvaluators (ise) vulnerabilities of Password managers

[AJJLagerweij]

Dear developers,
SecurityEvaluators (ise) released a report about vulnerabilities of password managers. Their report included among other KeePass 2.4 and a couple of other managers but did NOT include KeePassXC.

My question is if it would be possible to try to attack KeePassXC with the methods proposed and to see whether our manager is compromised as well.

Most interesting is that non of the managers were able to hide all 'secrets' or master-password after locking the database.

I hope that we can learn from mistakes of others, and fix (possible) issues in KeePassXC before someone else finds and misuses them.

Regards,
Bram

[phoerious]

The report points out nothing that we did not know before. We delete the Database object after it's been locked, but we cannot reliably scrub everything, since certain buffers may be duplicated in memory and out of our reach. We have had a patch in the pipeline to improve security a bit (but not entirely eliminate the problem), but it has not been merged so far, since it is a very deep change and may break things.
We do enable protection against memory dumps, though. In order to be able to perform a memory attack in the first place, you need to be root/administrator on the system, otherwise you will not be able to read anything from KeePassXC's memory.

[AJJLagerweij]

Thanks for your Janek,
I'm aware that this is problem (unintended copying of buffers) is not the fault of KeePassXC but of the operating systems or kernels on which we have no influence whatsoever. I would still be interested in the specific risks that are related to it, because only relying on admin/root protection does not suffice for the application that I'm using the software for.

1. Is it possible to leak the masterkey this way?
2. What 'secrets' can be copied. (all, only the used ones or the last used entry)
3. Are there any significant differences between, open and unlocked or relocked.
4. What happens after closing the entire program.
5. Are there significant differences in the behavior of different platforms and/or versions of it. (Windowns vs Unix)

If you require someone to help testing new security features I would be willing to make time for it. As I have no knowledge of cyber security I'm pretty useless in developing support. But I'm used to working with various operating systems and am not afraid to do some debugging.

[phoerious]

We have the full database in memory when it is unlocked and replace it with an empty database when the users locks it.

Relying on the operating system to prevent unauthorized access to your process memory is in fact the only thing you can do. Even if we kept only one password in memory at a time and none at all if KeePassXC is idle in the background and also carefully scrubbed every last evidence of it directly after use, it wouldn't matter if an attacker had gained local root access to your machine. Yes, they may not be able to find anything useful in memory right away, but guess what else they could do with your database or machine. There is absolutely no protection against password theft in this scenario whatsoever.

[richb-hanover]

@phoerious Thanks for this reassurance. Perhaps your answer could be added to the Security FAQ on the main site. Something like, "I have heard that many password managers have security vulnerabilities. Does KeePassXC have this problem?" with a reasoned explanation like the one you provide. Thanks again.

[AJJLagerweij]

Thanks for clarifying these things. I'm aware that opening the database on a 'compromised' device can lead to leaking of the secrets. I assume the solution to these problems would lay in the operating systems.
Thanks again for developing KeePassXC.

[naftulikay]

I'm not familiar with the codebase so please forgive me if this has been answered elsewhere: are you using mlock(2) and other analogues for other platforms to prevent the database and key master regions from ever swapping to disk? Corollary: when locking the database, are all the memory regions cleared and set to zero, or are the main structures just replaced?

[f35f0ef9d0e827dae86552d3899f78fc]

It sounds like I would be just as safe keeping all of my passwords in a text file as long as I don't transfer them to another computer.

[droidmonkey]

@f35f0ef9d0e827dae86552d3899f78fc that is absolutely incorrect.

[phoerious]

I hate that they wrote that. It is incorrect and only raises unnecessary FUD.

We do not currently prevent the database from being swapped out (and I don't think that would be practical at least not for the full db), but we have been evaluating various memory encryption options in the past and will continue to do so, so we only need to worry about where the master key is. As mentioned before, memory dumps are already prevented unless you are root on your machine (apparently a thing the vulnerable password managers have not done, otherwise there wouldn't be such a big fuss about it).

[rugk]

It also has been reported that KeePass uses some CryptProtectMemory on Windows, so do you use that, too? Why (not)?

If there is something similar on other OSes, maybe you can enable it, too?

In order to be able to perform a memory attack in the first place, you need to be root/administrator on the system, otherwise you will not be able to read anything from KeePassXC's memory.

Does this apply to all OSes?

[richb-hanover]

@phoerious (and other principals in the project) When "stuff" like this happens (I'll not use an expletive), there will be all sorts of panicky comments like those above. In a former life, I ran a company where this happened.

I found the best strategy is to write a clear, calm, straightforward description of what the software actually does, and post it widely (say to the FAQ). The note should:

• Acknowledge the ISE report (so readers know you're addressing that specific issue)
• Tell what KeePassXC does to protect the data
• Explain how that prevents/mitigates/minimizes the problem
• Note special circumstances (you need to be root, etc) required to exploit it
• Provide a candid assessment of the risks: (For example, "an attacker who would be in a position to do X to KeePassXC information would also be able to Y, which appears to be a far worse problem.")
• Finally, if there could be improvements that would make a sizable difference, describe when those would be available.

Best regards, and thanks for writing KeePassXC. I'm still going to be using it!

[f35f0ef9d0e827dae86552d3899f78fc]

@f35f0ef9d0e827dae86552d3899f78fc that is absolutely incorrect.

Sure, and I know this. But this reply does no good as it has no explanation. You can't just tell someone, "You're wrong," and then they change their mind. It takes convincing data. The reason I said my devil's advocate styled question was to get a positive explanation after the quote below:

Yes, they may not be able to find anything useful in memory right away, but guess what else they could do with your database or machine. There is absolutely no protection against password theft in this scenario whatsoever.

That response causes more unnecessary fear than the ISE article IMO. So, in addition to the bullet points that richb-hanover mentioned, I would like to suggest adding some examples of when KeepassXC is not vulnerable to the memory attacks that ISE demonstrated.

[richb-hanover]

PS Writing a note like the one I suggested is hard work and a pain in the patootie. I'd be happy to help with the note if that would help. (You could put the first draft in this thread.)

[droidmonkey]

I threw this together, any feedback? @AJJLagerweij @richb-hanover @f35f0ef9d0e827dae86552d3899f78fc

KeePassXC Memory Security

Some of you may have seen the recent vulnerability report from ISE that details various memory attacks against 1Password and KeePass, among others. Although KeePassXC was not mentioned, we have thoroughly reviewed the report and address some questions it raises below.

How does KeePassXC protect my data?

Similar to KeePass, we protect all data "at rest" (that is, when it is saved in the password database file *.kdbx). Aside from non-sensitive header data (such as initialization information for the encryption algorithms), your entire database (usernames, passwords, notes, etc) is encrypted using industry standard methods.

However, unlike KeePass, KeePassXC is a cross-platform application written in C++ using the Qt framework. We have worked very hard to be consistent across Windows, Linux, and MacOS platforms in terms of user experience and security. Each of these operating systems have different methods of handling memory that must be taken into account. This is a very complex topic with a lot of nuance. The following is a succinct breakdown of our security across the three platforms.

Please Note: memory attacks are generally not possible unless an attacker has physical access to your machine or a malicious application is running. If your computer is compromised in this way, then there is very little a program can do to protect its data. Your best defense against this threat is to have an up-to-date virus scanner and keeping your computer physically secure. Nonetheless, here are the techniques KeePassXC uses to protect your data:

Windows Memory Protection

KeePassXC uses modern Windows memory security techniques available to all processes. None of the other password managers featured in the ISE report have implemented this security. If they had, the ISE attacks would have failed outright! We specifically disable reading the memory of KeePassXC. (Note: it is not possible to prevent an administrator from accessing memory) We also disable "core dumps" which can expose secrets if the application crashes. Our memory protections can be readily tested by using Process Hacker as shown in the following screenshots comparing KeePassXC to KeePass:

KeePassXC currently does not encrypt data in memory nor explicitly clear sensitive data from deleted data structures. This is largely a limitation of using Qt which does not provide a manner to do this in their existing framework. KeePassXC also cannot prevent data extraction from a hibernation file which stores your computer's memory to disk when going to sleep.

Linux Memory Protection

KeePassXC prevents the use of ptrace and generation of core dumps. This prevents anyone, except the root user, from accessing the memory of the process. Due to the significant variety in different Linux distributions, we encourage you to ensure their kernel is compiled and run with sufficient protections to process memory.

The Snap and Flatpak distributions of KeePassXC run in their own sandbox (on Ubuntu) which significantly increases their memory security. The AppImage distribution can be further secured by running it in FireJail. If you are concerned with memory attacks, we recommend using these distributions.

MacOS Memory Protection

MacOS has similar protections to Linux: disabling the use of ptrace and core dumps. MacOS does have support for sandboxed applications, but KeePassXC currently does not take advantage of this. We are looking into this possibility for the future.

How can we be more secure?

We are currently exploring these methods to enhance memory security:

• Clear sensitive data structures after use
• Investigate Trusted Platform Module (TPM) to encrypt/decrypt sensitive memory
• Investigate Intel SGX (encrypted memory enclaves); we do not meet their development requirements and this is only for Windows

Details for the curious

Since KeePassXC is an open source application, we encourage everyone with the appropriate knowledge to review our code. The above memory protection techniques are all applied during the initial Bootstrap process before any data is loaded in to the application. You can see the code for this here: https://github.com/keepassxreboot/keepassxc/blob/develop/src/core/Bootstrap.cpp#L45

[phoerious]

A few remarks:

• I wouldn't call an anti virus program protection.
• Is our Windows DACL approach really that "novel"?
• AppImages are not sandboxed unless you run them in Firejail
• Snap is only sandboxed if AppArmor is enabled

[richb-hanover]

SPECTACULAR! A few nits from a mildly techie reader. Please correct me if I got it wrong, or if you said it better. THANKS!

Some of you may have seen the recent findings report from ISE recent vulnerability report from ISE that details various memory attacks against 1Password and KeePass, among others. Where _Although_ KeePassXC was not mentioned, featured, in the report we have thoroughly reviewed it the report, and have come up with some answers to the questions that you may have. address some questions it raises.

...

Similar to KeePass, we protect all data "at rest" (_that is, when it is saved_ in the password database file *.kdbx). Aside from non-sensitive header data _[such as ???]_, your entire database (usernames, passwords, notes, etc) is encrypted using industry standard methods.

...

It is important to note that Please Note: memory attacks are generally not possible unless an attacker has physical access to your machine or a malicious application is running. If your computer is compromised _in this way,_ then there is very little you can do to protect yourself. a program can do to protect its data. Your best defense against this threat is to have an up-to-date virus scanner and keeping your computer physically secure. _Nonetheless, here are the techniques KeePassXC uses to protect your data:_

...

KeePassXC takes a novel approach to memory security that none of the other password managers implemented. If they had, _the ISE attacks would have failed!_ not have been able to conduct the attacks that they did! We specifically disable anyone, except administrators, from reading the memory of KeePassXC. _(It is not possible to prevent an administrator from accessing memory. as an administrator.)_

...

Linux ...
If you are concerned with this attack vector memory attacks, we recommend using these distributions.

...

Mac
MacOS has similar protections to Linux: by disabling the use of ptrace and core dumps.

...

These are the current methods we are exploring to continue enhancing our memory security: We are currently exploring these methods to enhance memory security:

[droidmonkey]

I updated the post, great feedback @richb-hanover. I also changed WinWord for KeePass to be more dramatic of an example.

[richb-hanover]

I also changed WinWord for KeePass to be more dramatic of an example.

I like it!

Next step... Putting it on the Security section of the FAQ? Perhaps a question like, "Q: I've heard about 'memory attacks'. Is KeePassXC vulnerable?"

[droidmonkey]

Blog post is up!
https://keepassxc.org/blog/2019-02-21-memory-security/

[f35f0ef9d0e827dae86552d3899f78fc]

Thanks, @droidmonkey

[droidmonkey]

Any time, this was a good conversation

[richb-hanover]

I see the blog post with the direct link (above), but it's not visible when I click the "Blog" link at https://keepassxc.org/blog/

Also, this question probably wants to make it into your FAQ page as well, in the Security section. Thanks.

[droidmonkey]

Its in the blog link, try refreshing. I also already a recent blog post to the front page. The FAQ is a hot mess, it needs some house keeping first

[richb-hanover]

Yes, a refresh makes the blog posting appear. Thanks.

[rugk]

I'd would change a slightly confusing wording here:

-The Snap and Flatpak distributions of KeePassXC run in their own sandbox (on Ubuntu) which significantly increases their memory security.
+The Snap and Flatpak distributions of KeePassXC run in their own sandbox (Snap only on Ubuntu) which significantly increases their memory security.

As flatpak is sandboxed everywhere, as it uses Linux kernel components IIRC, but snap only on Ubuntu.

[AJJLagerweij]

Thanks, this was very useful, exactly what I wanted to see.
This post should take away the uncertainties, and is a lot better than the response of some other sources.