Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Someone told me that his company is storing all application data (at least the sensitive data I guess) in RAM for security. Their application runs for long periods of time, so data stays in memory for a long time.

How is this more secure if you keep it in RAM, instead of disk? Is RAM harder to access/exploit, or is it just because it's volatile?

share|improve this question
    
it sounds as potential problem to me, when all sensitive data remains in RAM. what happens if RAM is physically gone ? –  ElYusubov Jul 3 '12 at 14:41
1  
How does the data get into ram? Doesn't it have to start from a database or a file? Of course the data could be encrypted. –  mhoran_psprep Jul 3 '12 at 14:43
4  
Not to mention data in memory can get to disk when OS swaps. –  herby Jul 3 '12 at 14:46
1  
@herby: Having no swap solves that problem. –  Blrfl Jul 3 '12 at 15:02
1  
@Blrfl Or just marking the memory pages as non-swappable, using an API such as VirtualLock –  Polynomial Jul 3 '12 at 15:36
add comment

migrated from programmers.stackexchange.com Jul 3 '12 at 15:25

This question came from our site for professional programmers interested in conceptual questions about software development.

6 Answers

Keeping information in RAM can enhance security, if done right and if the requirements allow it. I'm going to show two security architectures where keeping the data in RAM provides a security benefit. These are fairly specific scenarios; most of the time keeping data in RAM doesn't help.

Protection against file dump attacks

Consider a web application that manipulates files on the server. One kind of vulnerability that it might have is to allow users to download files that are not supposed to be exposed remotely at all. If a piece of critical data is only stored in the memory of some process(es) (here it's not RAM that's relevant, but virtual memory as opposed to the filesystem), then it will not be revealed by a file exposure vulnerability.

Of course, the data may be revealed through other vulnerabilities, for example with an attack chain that first arranges to have the confidential data written into a file (such as an error dump of some kind) and then to have the dump file exposed.

Keeping the data in memory only helps if it isn't loaded from a file in the first place. Where do you get the data after boot? The data could be stored encrypted, but that requires someone to enter the decryption key after a reboot; this is no good for most web applications as they can't afford the downtime. The data can be stored in a file that requires additional privileges that the web server does not have: the web server process would start with elevated privileges, read the file, then drop privileges. This raises the bar for an attacker since they would have to find a local privilege escalation vulnerability in addition to the remote vulnerability that gave them a foothold. The benefit remains small because many attacks that give the attacker unprivileged local access also provides a way to inspect the memory of active processes.

Defense against some attacks with physical access

Information in RAM disappears if the RAM is powered off. Hence, if the attacker can only manage to grab hold of the target system by powering it off, he will have more trouble accessing data if it's only in RAM. However, storing the data in RAM won't do much good on its own, because RAM has some data remanence of a few seconds to a few minutes. (See also Recover the prior contents of RAM from a turned-off PC?). This is enough to reboot the computer into an operating system that's controlled by the attacker or to transfer the RAM sticks into another computer. (See also Are there volatile memory chips which dont retain data after power off?)

Encrypting the data helps, but you have to store the encryption key somewhere. And if you're going to encrypt the data, you can do this on a disk anyway. Encrypting most the sensitive data does help in that if the attacker is unlucky enough that the key is lost, the data is safe.

So in order for storing the data in RAM to enhance security, there have to be additional physical security measures. If the RAM is inside a tamper-resistant case that causes the power to be turned off if opened, it might be enough to exceed the RAM's remanence. For better results, tamper attempts should cause the motherboard to zero out the RAM before turning off the power (which means the motherboard should have a small battery). Encrypting the data helps because then only the key needs to be zeroed out, which takes less long. Even if the anti-tampering measures can be defeated with good enough tools, it makes the attack more difficult than a simple pass-and-snatch (an intruder with a bolt cutter is more noticeable than an attacker with a circuit board inside a cellphone case).

Going further, it can be worthwhile to encrypt RAM, and ensure that the key is kept in the processor cache or registers. The attacker typically has to reboot to try obtaining the key; rebooting quickly enough to find a pristine cache and without clobbering the cache is harder, and unplugging the CPU is harder than unplugging RAM.

There is of course always the problem of where the data is loaded from (or if it's encrypted, where the key is stored). Some use cases value confidentiality over availability and can afford to require someone to come and enter a key after each reboot (e.g. a big datacenter might have someone available to do it around the clock, in case an intruder gets that far). This security measure can also benefit systems that process data but do not store it.

share|improve this answer
add comment

They are feeling comforted by a false sense of security by obscurity

If someone gains root access to your machine then they can see all the contents of everything that any application can. Encryption won't help if the application has to be able to work with the plain text since the application will have to store the keys somewhere. Hiding those keys is where the security by obscurity comes from - eventually the intruder will find and copy them.

The above notwithstanding, having all data held in RAM does provide a measure of physical safety since loss of power means loss of data. However, once that data is out of RAM and on to a persistent store, say through a memory swap operation, then all bets are off. Also, any data center worth its salt will have a solid physical security plan in place that is insured against break-ins so it's kind of pointless.

Of course, keeping data in RAM for fast access for performance reasons is completely valid, just don't think that security is somehow enhanced as a result.

share|improve this answer
1  
One improvement on this is to store the encrypted data in nonpaged pool via a kernel module. That way you're placing the data in the same area of the system that you would consider the final bastion of integrity. Once kernel-mode is compromised, the entire box is compromised. Not sure how this stacks up on Linux systems that allow /dev/kmem access to root, but at least it adds an element of complexity to a potential attack. –  Polynomial Jul 3 '12 at 15:41
1  
Alternatively, they could use a HSM. –  Polynomial Jul 3 '12 at 15:42
2  
@Polynomial "that allow /dev/kmem access to root" I believe this is usually turned off on "harden" sensitive systems –  curiousguy Jul 3 '12 at 16:25
    
Your first and last sentences are too peremptory. It depends what the flow of data is, as you discuss in between. –  Gilles Jul 3 '12 at 18:10
    
@curiousguy Figured as much. I'm not that familiar with Linux hardening, but I had a feeling such a thing wouldn't be allowed. –  Polynomial Jul 4 '12 at 14:12
add comment

It is marginally harder since it does go away when the machine is powered off. It requires someone to gain access to the machine when it's running rather than just stealing the hard-drive/laptop.

That said, the memory needs to be populated from somewhere. If that's a remote machine, then you've opened that avenue of attack which is usually more risky than keeping the data on disk in the majority of scenarios.

share|improve this answer
    
"That said, the memory needs to be populated from somewhere." Hear! hear! "If that's a remote machine" if that's what the person recommending the "all in RAM" solution, they should say so. "I keep data in RAM" is an empty security concept if you don't say where it comes from. –  curiousguy Jul 3 '12 at 16:34
add comment

Memory might be harder to retrieve sensitive information from than disk, but the possibility still exists. If the data is not also encrypted, then it can be compromised. We recently looked into secure strings in PowerShell for this reason. Yes it needs to be plain text at some time, but not while waiting to be used. Data from RAM can be retrieved from a forced crash dump, and just because it's in RAM doesn't mean it never gets on the disk during a paging operation.

share|improve this answer
1  
In order for storing data in RAM to help, you'd have to design the whole system for this kind of security, it's not something you can plug into an existing infrastructure. –  Gilles Jul 3 '12 at 18:07
    
@Gilles - I believe you are correct for large amounts of data as the OP mentioned. PowerShell has methods specifically for working with secure strings, but usually it's a small amount of data, like a few variables, or a password. –  Bratch Jul 3 '12 at 21:57
add comment

I'm surprised that nobody has pointed out the danger of core files. Most Unix or Linux variants will helpfully write a "core" file to disk when a process crashes. The core file usually contains that process's RAM contents at crashtime so that you can try to find what data or condition cause the problem. Later, a user with the right privileges can access this file and search for remnants of the data that the dead process once kept in memory. For this reason alone I'd say that data kept in memory is not really any more secure than data stored on disk. Anyone have anything to add about this?

share|improve this answer
    
Anything to add? Sure: ulimit -c 0. Obviously, if you want data to be kept in RAM, you have to disable things like swapping to disk and crash dumps. –  Gilles Jul 3 '12 at 23:32
add comment

I think this is mostly silly. If an attacker can access the data on your hard drive, they will almost certainly have access to your memory as well (and vice versa). Regardless of where the data lives, it needs to be encrypted. That's the real solution to this problem.

Besides, keeping all your data in memory can have some bad side effects in your application (memory bloat, more complicated code, etc.) This isn't the "right" way to solve they problem.

share|improve this answer
    
“Regardless of where the data lives, it needs to be encrypted.” And where do you store the encryption key? “This isn't the "right" way to solve they problem.” How can you know, without knowing what their problem is? –  Gilles Jul 3 '12 at 18:05
add comment

Your Answer

 
discard

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