6

I know data-remanence is a concern on hard drives, but is it a concern on RAM? For example, once a program completes, is its data still available on RAM, just as data on a hard drive remains after being deleted?

Edit: In this case, I am not as worried about data that could possibly remain after the computer is shut down. I am moreover thinking about a situation where a hacker compromises a system that is still running, and is able to access the memory. Does the data remain in RAM long after the program that was using it is terminated?

Jonathan
  • 3,157
  • 4
  • 26
  • 42
  • 1
    Relevant: http://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe and http://security.stackexchange.com/questions/7299/how-can-the-impact-of-cold-boot-attacks-be-minimized/ – Polynomial Dec 04 '14 at 17:12
  • See also: [the application-level view](http://security.stackexchange.com/questions/74280/would-it-be-good-secure-programming-practice-to-overwrite-a-sensitive-variable) – Gilles 'SO- stop being evil' Dec 04 '14 at 18:04
  • The following question might also be of interest: [Protecting Crypto Keys in RAM](http://stackoverflow.com/questions/17147890/protecting-crypto-keys-in-ram) – Will Dec 05 '14 at 03:51

1 Answers1

11

It can be.

Generally speaking, programs while running don't tend to wipe out their data (they do, after all, tend to need it), and any process with the ability to access other programs' allocated RAM can, in fact, read it. This is how, for example, the recent spate of big box store hacks were able to leak so much credit card data -- the attacks were carried about by rogue programs that scoured the running POS machine's RAM and copied anything that looked like card data. [I can't at the moment find a source to back this one up, I'll keep looking and edit it in later.]

Once a program terminates, the data that was in its RAM may remain around indefinitely if no other process gets allocated those same addresses and overwrites it with its own data. On modern operating systems this again requires the ability to read RAM not allocated to the process doing the reading1, and even then is unreliable at best, especially on modern systems that are constantly doing all kinds of things.

Both of these can be mitigated, if not outright prevented, by never allowing untrusted processes to run with root/administrator privileges: limited users simply do not have the ability, barring holes in the OS's security model, to access this RAM.

And, of course, there's our good friend the "cold boot attack", where encryption keys etc. are read from RAM after the machine has been powered down. This requires physical access to the machine, a boot disk (or specialized hardware), and quick timing (as data remains resident in RAM for only a short time after it's powered down).

As a quick footnote, the risks of data remanence on hard drives are rather overblown: Once data's been overwritten, it's gone. The "Gutmann 35-pass method", for example, is not only a fundamental misunderstanding of Dr. Gutmann's research, but wholly unnecessary -- a single pass with any data -- ones, zeros, random noise, kitty pictures -- is all that's really necessary. If it's not overwritten, however -- if it's merely deleted -- then it does hang around, though. Data remanence on RAM is similarly an often-overstated risk, though just like hard drives it can and does leak information if you're not careful.

1 The reason is that modern operating systems actually take the time to wipe out RAM before allocating it to a new process, specifically to avoid leaking potentially sensitive data to processes that start up and then read uninitialized data (which in the past is how such leaks were carried out).

Community
  • 1
Kromey
  • 455
  • 3
  • 7
  • 1
    Props, I never really considered the practicality of such data-recovery. – Desthro Dec 04 '14 at 19:42
  • 2
    It's worth mentioning that the Windows kernel, at least, has a worker thread dedicated to zeroing freed pages so that it can satisfy future allocations without delay. [source1](http://stackoverflow.com/questions/18385556/does-windows-clear-memory-pages), [source2](http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100%28v=vs.85%29.aspx) – nobody Dec 04 '14 at 22:21
  • Your second paragraph I find a bit hard to follow. I segmentation fault will occur if a process tries to read memory not belonging to it, the memory management unit would see to that. Are you saying sometimes there can be a bug and a fault doesn't occur and it can be read? – Celeritas Dec 05 '14 at 03:04
  • @Celeritas Sometimes there can be a bug, yes. There are, however, ways around the segfault; it's been a long time since I've coded at that low a level, and I no longer remember the specifics, but a process with sufficient privileges *can* read memory allocated to other processes without provoking a segfault. This is how, for example, many debuggers work, as well as a key tool in modding games that are not generally moddable involves doing the same thing -- basically grabbing dumps of the game's RAM so would-be modders can hack it. – Kromey Dec 05 '14 at 07:14
  • It's the "sufficient privileges" bit that's important, hence why I stressed in my answer not running untrusted programs with elevated privileges. – Kromey Dec 05 '14 at 07:15
  • Wouldn't the programs you give as examples be designed for it, for example it is possible to set up interprocess communication or have threads to communicate with each other but that's a design that has to be intentionally coded (for example a debugger probably has some access to the programs memory because it is the parent of the child process). – Celeritas Dec 05 '14 at 08:06
  • @Celeritas In many cases that's how it is done, yes (e.g. when you compile a program with debug options), but that's not always the case, especially in the example of modders hacking on a game not designed for modding. It does (barring a bug/flaw in the OS) require elevated privileges, however. [Here's one example](http://www.codeproject.com/Articles/670373/Csharp-Read-Write-another-Process-Memory); without modifying notepad.exe, it shows how to do it with simple code. And, again, it's dependent upon permissions in the OS, but root/admin could do this for *any* process. – Kromey Dec 05 '14 at 16:41
  • @Kromey it seems that link is dead – Celeritas Dec 05 '14 at 22:37
  • 1
    @Celeritas It works for me. I guess if you can't see it, you'll just have to trust me that it totally validates everything I've said, and also proves incontrovertibly that apples are the far superior fruit! Or I can just copy/paste the link here without formatting in the hopes that this will work for you: http://www.codeproject.com/Articles/670373/Csharp-Read-Write-another-Process-Memory – Kromey Dec 05 '14 at 22:40
  • It would be nice / more secure if the operating system cleared out the data when the process terminates vs. when a new process uses the data (or possibly did both). – Jonathan Jan 22 '15 at 20:21