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.
Is it more secure to you keep sensitive data in RAM instead of disk? Is RAM harder to access/exploit, or is it just because it's volatile?
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.
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.
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.
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.
/dev/kmem access to root, but at least it adds an element of complexity to a potential attack.
Commented
Jul 3, 2012 at 15:41
/dev/kmem access to root" I believe this is usually turned off on "harden" sensitive systems
Commented
Jul 3, 2012 at 16:25
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?
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.
Commented
Jul 3, 2012 at 23:32
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.
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.
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.
What can help is new memory encryption technologies like Intel's SGX and AMD's SEV that rely on a hardware root-of-trust. In the case of Intel SGX, an application's data is encrypted in memory using a key that is accessible only to the CPU, and can be pinned to a specific code, such that no other application (even a root user) would be able to access the data. Moreover, it is possible to encrypt stored data (at-rest) using a CPU specific key, which prevents some of the aforementioned attacks.
VirtualLock