Jump to content
Enpass Discussion Forum

Security concern


Bill Rossum
 Share

Recommended Posts

I've been playing around with the HxD editor today, and it has a nice built in feature that lets you view the memory of another process. This gave me the idea to check whether Enpass was exposing your sensitive information in memory. I opened up the running Enpass process in HxD, and did a simple string search for one of my passwords. Surprisingly, I was able to find multiple occurrences of my password stored as a raw string in memory, even while Enpass was locked (without PIN enabled). I was also able to find secure notes, usernames, TOTPs, and other sensitive information that I was not even accessing in the Enpass window. I tried finding many different entries, and one time I found a JSON encoded string containing lots of sensitive data including passwords, which would make it especially easy for an attacker to dump the database. I understand that there are some cases where exposing the sensitive data in memory is necessary, but it is concerning to me that they lots of it seem to be littered everywhere, especially when unnecessary, and even after locking Enpass. Another thing to note is that HxD didn't even require UAC privileges to view the memory, which means this information is exposed to literally any other program running on your machine. Though I haven't attempted to, I think it would be quite easy to write a program to pull your passwords from the Enpass memory. Surely it is possible to encrypt the information in memory, and only expose it when displaying it on screen or copying it to the clipboard? Perhaps it would also be beneficial to clear the memory when you lock the database, with the exception of when a PIN is enabled?

Enpass_2017-09-28_15-36-28.png.e6d63430f0b96c0a82c992b7d3a1bdfc.png

Screenshot taken of HxD after locking the wallet:

HxD_2017-09-28_15-37-56.thumb.png.8bf3a9db3cbb4f0c7b7715c0774de05d.png

Edited by Bill Rossum
Additional question
Link to comment
Share on other sites

Hi @Bill Rossum

We really appreciate your time taken for these findings about Enpass. 

We certainly do clear memory where ever it is possible but we can't clear the memory of objects we do not own, i.e. objects created internally by other libraries those Enpass is using and being displayed to you by HxD, mainly:

1. SQLCipher -> Result of queries are not zeroed out by underlaying sqlite code, so you are seeing json littering. 

2. GUI Toolkits -> Enpass heavily uses Qt framework (www.qt.io), which makes us possible to provide Enpass on Windows, Mac and Linux. We have no control over Toolkit objects internal memory allocations.

This is one of the main reason why we are refactoring Enpass and writing it from scratch for next major release where the whole core is being written in C/C++ offering a greater control over memory (locking, zeroing etc) and internal objects' lifespan.

And the final verdict is a password manager can't be more secure than underlaying OS. If OS is set to allow any process to peek into other process' memory, there is very little a password manager can do.  If someone can install a malware to spy your system's memory it means he has that much control over the target OS that he can circumvent every protection of any password manager, for example by installing keylogger, replacing the whole Enpass binary etc. Thanks again for putting up this discussion here.:)

 

Link to comment
Share on other sites

Are you clearing the UI elements and closing the SQLCipher DB when Enpass is locked (either PIN or fully locked) so we can't access the clear data in memory ? If yes I would say it is good enough, we can't do much against unencrypted data in memory while we are using the data.

Edit: I misread it looks like it is also in clear when locked, not cool. It should be technically doable without too much changes to clear the UI elements and close the DB in this case.

Edited by MatMaul
Link to comment
Share on other sites

Ok great that it closes the DB in the full locked case.

Can we have some details about how the PIN is handled right now ? is it stored in the encrypted DB and then compared since the DB is available ? or are you storing a hash of the PIN for comparison ? Both ?

I am trying to think about a way to be able to close the DB in the PIN case but I need a bit more info.

Thanks.

Link to comment
Share on other sites

15 hours ago, Bill Rossum said:

Surprisingly, I was able to find multiple occurrences of my password stored as a raw string in memory, even while Enpass was locked (without PIN enabled).

And I didn't check but this statement contradicts what you just said. Do you completely destroy the UI elements when fully locking or just hiding them ?

Link to comment
Share on other sites

@Hemant Kumar

I re read your first answer and I missed a lot of infos so sorry for the multiple unstructured posts and the possibly redundant questions, I usually do better. :)

Last point regarding your point 1 for the cached json in sqlcipher : there is no way to purge this cache after closing the DB ? If so it looks like a huge problem in sqlcipher no ? It looks weird to me that a security oriented software can't zero out all clear text information when fully closing an instance.

Link to comment
Share on other sites

By the way I am asking a lot of questions, it is not to annoy you but because I care ;)

I was an happy paying customer of LastPass and looked a bit elsewhere when their price went up , I could just have stayed on the free tier but I really like your simpler approach, and your extensive updated app ecosystem.

Link to comment
Share on other sites

Hi @MatMaul

There is nothing like annoying in your queries. This is the purpose of discussion forums and we really appreciate your presence here. And many thanks for choosing Enpass and showing your trust. Security is an ongoing process and you shall definitely see improvements in next major release.

 

17 hours ago, MatMaul said:

Last point regarding your point 1 for the cached json in sqlcipher : there is no way to purge this cache after closing the DB ? If so it looks like a huge problem in sqlcipher no ? It looks weird to me that a security oriented software can't zero out all clear text information when fully closing an instance.

Let me attach here the answer from SQLCipher author himself. It should make things clear.

59cf730c9d9a8_sqlcipherreply.png.9ccd7ba95f4b3d981fa341aafb39e83f.png

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...