How do programs prevent data from being leaked?

Question

There are many programs out there that offer encryption and key management.

From what I understand when a file is saved on a hard drive, then there will sometimes (often?) be copies of the file in the memory and maybe even other places on the hard drive. When one enters a password/key phrase in a program to unlock a database I guess that the password will live in the memory for at least a short period of time. I had heard about the audit of VeraCrypt and that one problem was the use of memset when clearing sensitive data from the memory (page 9 here).

My general question is: How do programs like VeraCrypt, 1password, keepass, GPG, LastPass, AES Crypt, and many others deal with these issues of multiple copies of files and having a copy of the password/key/data in the memory or other places of a hard drive? Are these things even a security concern?

Like, we VeraCrypt, is this a general problem that shows up in audits?

(I am just asking out of curiosity.)

Answer 1

You are mixing separate things here, namely encryption software and password managers. For both tho, there is no way around storing the key in memory and the problems can be reduced to one:

• If you want to store passwords like in KeePassX, you have to unlock the password database once and keep it open (so you can autotype them via hotkeys).
• If you encrypt files, you have to enter your master password once and keep the files open.

In either case the password will be in memory for a finite time and you need to overwrite it after using it in order to make sure it doesn't stay there. If you simply reallocate the memory, it's not guaranteed to be overwritten ever.

memset can set a memory block to whatever you want it to be, so it could help us here. Problem: If you use compiler optimizations, the compiler might think memset is useless and remove it for more efficiency.

This is why for example VeraCrypt includes special functions like RtlSecureZeroMemory and its wrapper method burn to ensure memory will be reset, like this:

BootArgs = *bootArguments;
BootArgsValid = TRUE;
burn (bootArguments, sizeof (*bootArguments));

Of course this doesn't make deletion 100% guaranteed, because now you have to ensure that there is no possible execution path that forgets to call this function.

In the latest audit of VeraCrypt it was revealed that there is one occasion where burn is called after a code segment where a TC_THROW_FATAL_EXCEPTION can be thrown, thus leading to sensitive data remaining in memory.

This is generally one of the problems in designing safe and secure programs, if you implement methods to prevent memory leaks you have to ensure there is no way to prevent them from getting called.

Answer 2

How do programs like VeraCrypt, 1password, keepass, GPG, LastPass, AES Crypt, and many others deal with these issues of multiple copies of files and having a copy of the password/key/data in the memory or other places of a hard drive?

It will vary from product to product. This is why third party audits are valuable - to validate that the approach is secure and implemented correctly.

Are these things even a security concern?

Yes and no. It's often important to put security questions into context. Having extra copies of a password database isn't ideal, as it makes information disclosure more likely, but if appropriate protections are in place for the files, and the database is encrypted, it's unlikely to be exploited.

On a similar note, having passwords in memory isn't optional if you're using a password store. Is it worth the risk? Probably.

Answer 3

Process isolation

Having sensitive data in memory is not a security problem by itself - in any "proper" system it's not accessible to other processes and can be used only in the appropriate, secure manner.

It does imply a certain risk of disclosing that data - namely, leaving a temporary copy after the memory is deallocated and then possibly allocated to another process; or if the memory area is swapped out to disk, but these can be mitigated with reasonably simple technical measures, e.g. overwriting the memory area after use and before deallocation, and marking the memory page so it won't be available for swapping respectively. When developing such software, you need to ensure that these steps have been taken and that sensitive data doesn't "leak" in this manner.

Outside of that, OS will enforce process isolation so that this sensitive data (as all other data) is not accessible for other processes. You should still take steps to minimize the time that sensitive data is in memory to reduce the risks in case of a compromise in your software or the OS (e.g. the "heartbleed" openssl vulnerability), so it's a security concern but it's acceptable and secure practice to keep sensitive data in memory when necessary.