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.

[Emma-Walker]

How can we be more secure?

How about securing de-bulleting with with the master password? So whenever someone clicks on the eye, KeyPassXC would ask (optional) for the master password. It worries me that once the database is open, any co-worker can see my passwords just by clicking the eye. This applies to my children, too, if for example I let them play games on my Windows account.

I think there should be an option like [x] ask for master password when unhiding passwords ( ) first time (o) every time

Protecting unhiding should apply for the browser integration, too.

[JohnLGalt]

How can we be more secure?

How about securing de-bulleting with with the master password? So whenever someone clicks on the eye, KeyPassXC would ask (optional) for the master password. It worries me that once the database is open, any co-worker can see my passwords just by clicking the eye. This applies to my children, too, if for example I let them play games on my Windows account.

I think there should be an option like [x] ask for master password when unhiding passwords ( ) first time (o) every time

Protecting unhiding should apply for the browser integration, too.

I believe that that is the reason the automatic lock functions exist in the first place.

For example, I have my database set in regular KeePass 2.47 to automatically lock the database whenever my machine locks. And I have Windows set to use dynamic lock with my phone, so whenever I get up and walk away from my desk with my phone, the computer locks - which forces the database to lock as well.

I've only been using KeePassXC for a week or two, but it has the same feature. If you look in Tools --> Settings --> Security, under convenience, you see a whole heap of settings, including my fav "Lock database when session is locked or lid is closed".

But under that is also a couple of other lock scenarios, like locking when minimizing, and even re-locking after an autotype.

There is also one there that sounds like what you're asking for, but, doesn't work the way you're describing, so I'm misinterpreting it.

However, my point is that if you have to enter your master PW to just show the PWs, might as well just lock the database every so often, and when you lock your computer, and when you minimize the app, and when it performs and auto-type....

You'll be entering the master PW to unlock the db anyway, same as you would to just unhide the PWs themselves.

[Emma-Walker]

I believe that that is the reason the automatic lock functions exist in the first place.

I like those auto-lock functions but they are different from what I have suggested.

Take the example I gave: I want my children to be able to play on my Windows PC. I want the KeePassXC databases to be unlocked so that they can login into a Roblox account or Steam account. But I do not want them to be able to click around and uncover all websites with my passwords.

[michaelk83]

This was discussed in #4301 and elsewhere. Even if the main UI is inaccessible, if the DB is unlocked, they can still discover passwords via auto-type.

I suggest you should make a separate DB for your kids' passwords, and keep only that unlocked.

[Emma-Walker]

This was discussed in #4301 and elsewhere.

It was indeed and it was dropped without any valid reason except "It would be confusing for the average user to have to type in a password" and "The database is still encrypted in memory". In my view these aren't valid reasons because they don't address the issue. The issue is to make it harder, not to make it impossible.

they can still discover passwords via auto-type.

Nobody doubts that once the databases are open, they can be spied upon or somehow extracted. But it would make it much harder for the average user than the way it is now. It's ridiculous easy to open the app and export all data. That's literally the only reason why I don't want to use the application and why I prefer to continue to use Firefox which has my suggestion implemented (= master password for opening/viewing/exporting/... data).

I suggest you should make a separate DB for your kids' passwords, and keep only that unlocked.

That's so much more fuss than to simply add an option to password protect the application or to password protect the viewing of passwords.

[f35f0ef9d0e827dae86552d3899f78fc]

I suggest you should make a separate DB for your kids' passwords, and keep only that unlocked.

That's so much more fuss than to simply add an option to password protect the application or to password protect the viewing of passwords.

Using auto-lock and another database is a great suggestion. If you don't like that option, how about creating another system account for the children and using the system's built-in vault / wallet program to unlock when the user logs into the system? Put your secrets you want to share in there.

I don't know why you would let another person use your own user space when you're security conscious anyway. Steam can save credentials for the current user and has Family settings to limit which games an account has access to use. So, you could set up Steam in the children's system account as well. Roblox has Family settings that can be managed from their web interface also.

[Emma-Walker]

What you suggest is still way more complicated than simply adding an optional password prompt to KeePassXC.

Using auto-lock and another database is a great suggestion

No, it's not. It makes things ridiculously more complicated. Moreover it does not address the main issue: Forgetting to lock the databases even once, can render years of efforts useless. Moreover it's somewhat laughable that KeePassXC is less secure than Firefox's built-in password manager.

Adding an additional and optional layer of security would solve all of the issues I (and others) have mentioned. The topic of this thread is vulnerabilities of password managers. A suggestion like "Create another windows account" doesn't address the issue and moreover it tries to solve a vulnerability by making the OS responsible.

I don't know why you would let another person use your own user space

Using KeePassXC I would definitely not allow anyone near my Windows Account. Not my children, not my wife and no friend who just wants to check his mail. I mean, you don't even have to type in the master password to export all credentials in clear text. Click on KeePassXC -> Databases -> Export -> CSV -> Save. No password, no check, nothing. It's too ridiculous that I have to point out that something like this is a security issue. This should have been addressed and solved a long time ago.

[JohnLGalt]

Not to argue with you, but what you are proposing is not a true lock, only a visual effect of not being able to see the password - if your database is not locked, it is still accessible in a multitude of ways. It was because of this that I suggested the auto-lock functions to prevent this from happening in the first place - you can't forget if the system does it for you automatically.

And the use of separate databases is a GREAT idea to prevent your kids from ever accessing any of your own, private data - because it is never opened in the first place when they are using the system. Heck, you can even use the regular KeyPass application and set the default settings on that differently from the KeePassXC settings.

For example, your database is opened in KPXC, and is set to always close after a certain time period, when you minimize it, when you auto-fill in data, and even when the machine locks itself.

Your kids, OTOH, use the original KeePass 2.47 app from Dominic, using their own database of passwords that they need, and they can set it to always leave it open / not lock after certain actions . time periods - functions being used.

Now, your stuff is safe and their stuff is usable and neither interferes with the other.

And, for what it is worth, you can do what you say is a security issue on any device. In Firefox, you're entering the master password to get access to the passwords - same as when you open the database in KeePasXC - or KeePass. Or LastPass. Or any other password manager.

An analogy - you want there to be an additional lock on, say, your closet, so that even if your kids get into the home office that you keep locked, they cannot get in the closet because it is still locked. Whereas the functions built into KeePassXC app (and original KeePass app, as well) have settings to make sure that your stuff is not ever protected - if you enable them. It's like having one of those biometric locks that auto locks itself on your main door to your office - so that it is never left unlock even accidentally.

[michaelk83]

Moreover it's somewhat laughable that KeePassXC is less secure than Firefox's built-in password manager.

I think you have it backwards. Keeping the DB permanently unlocked is bad practice, and far less secure than keeping it locked. Having the option of a visual-only "lock" encourages that bad practice by giving users such as yourself a false sense of security (and I admit I fell into that trap myself until very recently). It doesn't protect even against a mildly sophisticated attacker. Whereas, the auto-locking options actually secure the DB, and make sure that you don't forget to lock it manually.

Likewise, keeping everyone's passwords in one big DB is less secure than having separate DBs for each user, or at least for each group of users. It's really not that difficult to set up.

I might agree, however, that at least the export function should be password protected. Although the passwords can be collected from an unlocked DB by other means, the export function is automated. But again, a mildly sophisticated attacker can easily write a script to automate any of the other means of access - unless you actually lock the DB.

Forgetting to lock the databases even once, can render years of efforts useless.

That's what auto-lock is for.

It is somewhat inconvenient having to enter a long passphrase each time you need access, but there is always a trade-off between security and convenience. This will get easier when QuickUnlock is implemented (hopefully soonish).

[droidmonkey]

I find it slightly amusing that you think developing a brand new feature, testing it, documenting it, and deploying it is far less work than just using two databases. Discussion closed on this one. Security through obscurity is not on our feature list, and I am going to make sure it never is.