Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I saw that KeePass not only encrypts its password-database-file, it also can encrypt the passwords it holds in memory. This is just an example. I thinking of a new project dealing with sensitve / personal data and now I ask myself if I should encrypt the data hold in memory, too. This project would be implemented with Java SE and an additional android application. There will be no data stored in the cloud or on a server in this special case. Data from android will be imported by the Java SE Desktop application via cable connection.

But why is this necessary at all? Don't modern operating systems work with virtual memory management so that it is not possible for user-space / user-mode processes to access other processes memory?

Is it just another defense line if there is an OS vulnerability making foreign memory access possible? In that case I think it would be much easier to steal the data file and use a key-logger to catch the password the user enters instead of stealing the data through memory access.

share|improve this question

migrated from Sep 18 '12 at 12:16

This question came from our site for professional and enthusiast programmers.

The problem with encryption is that it only shifts the problem to where to store the key. – CodesInChaos Sep 18 '12 at 8:47
Data may be swapped out to the page file, and many OS do not clear the page file when shutting down. With physical access to the machine the page file can be easily accessed and searched (and there are ways to make it more likely that data of intrest is swapped out, and then one could pull the power cord to prevent the OS from shutting down...). Still, in memory encryption only makes it more work to access the encrypted data, since the code and key to decrypt it can be obtained by the same method... – Durandal Sep 18 '12 at 11:21
"Don't modern operating systems work with virtual memory management so that it is not possible for user-space / user-mode processes to access other processes memory?" no, they don't. At least, not always. Windows lets you access the memory of any process run by the same user via an API. – Mints97 Mar 14 at 14:52

6 Answers 6

Memory can become visible to other processes by:

  1. being available once the original process using it has returned it to the OS. Memory isn't cleared and a successive process could perform a malloc() and retrieve info belonging to a previously running process (note chapter 8 of Linux Device Drivers - particularly the footnote on the first page)
  2. pages being swapped out to disk by the OS. These can then become available to a process watching the disk/storage.

Consequently unencrypted memory can become visible to other processes.

This is a very interesting link, and note this quote:

This volatility depends greatly on the computer in question, however - for when a computer isn't doing anything anonymous memory can persist for long periods of time. For instance in some computers passwords and other precalculated data were easily recovered days many after being typed or loaded into memory

share|improve this answer
Can you name a modern OS that has property 1? Windows NT does clear the memory before handing it out again. Property 2 requires admin privs, so you should not worry about other processes doing this, but about data remaining on the disk after the program terminates or the system restarts. – CodesInChaos Sep 18 '12 at 8:40
I don't know about Windows NT, but I wouldn't expect Linux to return you a cleared memory block from malloc() or sbrk() – Brian Agnew Sep 18 '12 at 8:41
I know attributes of Java objects are cleaned / initialized at instantiation time. But what after memory release / JVM termination. Will there be a cleanup? – user573215 Sep 18 '12 at 8:53
malloc might reuse memory used by the same process earlier without clearing it. But an OS reusing uncleared memory across processes seems very dumb. – CodesInChaos Sep 18 '12 at 10:02
The link talks about kernel memory. Memory allocations of usermode processes are something different entirely. – CodesInChaos Sep 18 '12 at 11:17

In a perfect world, you are right: there should be no point in keeping data encrypted in RAM. The OS should keep strong separation between processes, clear RAM when it is reallocated to another process, and, if the attack model allows for an attacker stealing the device afterwards and doing some harddisk analysis, encrypt the swap (or use no swap at all, which may make more sense for a device with Flash-based storage).

In a realistic world, where operating systems and system administration are human endeavours and thus inherently non-perfect, you might want to add some safeguards, including keeping data encrypted in RAM and instructing the OS not to write data in swap space (on Unix-like systems, this is done with mlock()). Still, this encrypt-in-RAM things is more a psychological ritual than a true defense; its main virtue is in making the developer feel better.

Don't bother with doing that in Java, anyway. The garbage collector will copy objects in RAM transparently (this is part of the most efficient GC algorithms and you cannot prevent it) so no level of encryption by your application will guarantee that no clear version of the keys exist in RAM at any time.

share|improve this answer

Modern operating systems work with virtual memory management so that by default it is not possible for user-space / user-mode processes to directly access other processes memory.

But in Windows (don't know if this apply to Linux, too) there are interfaces that allow standard users to access the process memory of other processes running with the same credentials.

There are many programs that use this interface. A very simple example is HxD - a freeware hex editor that allows to view and even edit the process memory of other processes.

share|improve this answer
But encryption doesn't help here, since you can use the same API to read the key. These memory APIs are also restricted, so only sufficiently privileged processes can read the memory of another process, by default they need to run on the same user, or be an admin. – CodesInChaos Sep 18 '12 at 13:40
You are right, in that case it is only for obfuscation purposes. – Robert Sep 18 '12 at 14:06
In Linux you can do this by reading /proc/$pid/mem (as the process you want to read, or root). – Brendan Long Sep 18 '12 at 15:58
@CodesInChaos, doesn't this only apply to keys stored in ram? If a generated key is used, for which only some sort of initialization vector exist in memory it would not be easily visible. But this still tend to be obfuscation only. I agree – Samuel Aug 20 '14 at 13:16

There are some issues that are specific to the Java world that you have to consider. It is a normal practice that one makes heap dumps of the JVM if a technical issue rises. I'm dealing with an app that even has a dedicated UI for that. This might be incredibly valuable e.g. for finding memory leaks. And sure - yeah - the sensitive information goes into the dump. So if someone breaks in the app (e.g. bypasses the login with an SQL Injection :) )... :X. Or if the administrative user is a curious person ... :X

I know that this should not happen in the "ideal world".

Also you may configure the JVM to make a dump on out of memory exceptions. Since Java 1.4 this might look like this:

-XX:-HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=<path to dump file>

An attacker may find an exploit that makes the app crash with out of memory and may find another exploit (e.g. file path traversal bug) to steal your dump!

The other thing that you should think about is that some sensitive data will have to make its way into your app somehow. So in certain moments you'll have it in memory. There is little or nothing you can do about it. But what you can do is to clean it faster. For example take a user password. If you store it in a String instance then you do not have much control on when it will be garbage collected. Thus usually nice API-s do process such data in character arrays (char[]) that can be zeroed after usage.

share|improve this answer
Can you tell me the Java language specification part where it is said that writing to a char[] actually performs the writes in-place? – user1050755 Mar 19 '14 at 10:58

The reason why it sounds like a good idea is that you will want to protect the data from being stolen while resident in memory. This is under the assumption that the data in the actual database is encrypted (as all PII should be) but sits un-encrypted in memory as it is processed. This would be quite difficult to do for a variety of reasons outlined by other commentators and would introduce a great deal of complexity in terms of how the applications will work with the encrypted data in memory.

What is a better and more feasible solution is to ensure proper access control to the Database / system and also ensure that the DBMS runs under a "normal" user account and not an elevated account such as SYSTEM etc. There is also additional detective controls you can put in place such as a DBMS monitoring tool that you can configure to look at large selects on sensitive tables etc and report back on anything that is out of the ordinary. This way you can see if there is some select or process trying to get large amounts of data out.

share|improve this answer

Google has an exploit called RowHammer which allows a user to read the contents of RAM that is adjacent to the data being written to. Encrypting the RAM would make this exploit much more difficult.

“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.

We don’t know for sure how many machines are vulnerable to this attack, or how many existing vulnerable machines are fixable. Our exploit uses the x86 CLFLUSH instruction to generate many accesses to the underlying DRAM, but other techniques might work on non-x86 systems too.

We expect our PTE-based exploit could be made to work on other operating systems; it is not inherently Linux-specific. Causing bit flips in PTEs is just one avenue of exploitation; other avenues for exploiting bit flips can be practical too. Our other exploit demonstrates this by escaping from the Native Client sandbox.

share|improve this answer
+1 for Rowhammer! – Mints97 Mar 14 at 14:54
It doesn't allow the user to read RAM adjacent to the data being written, but rather allows one to increase the probability of data corruption on RAM adjacent to the data being written. – supercat Sep 9 at 21:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.