7

There's a SecureZeroMemory() function in WinAPI that is designed for erasing the memory used for storing passwords/encryption keys/similar stuff when the buffer is no longer needed. It differs from ZeroMemory() in that its call will not be optimized out by the compiler.

Is it really so necessary to erase the memory used for storing sensitive data? Does it really make the application more secure?

I understand that data could be written into swapfile or into hibernation file and that other processes could possibly read my program's memory. But the same could happen with the data when it is still in use. Why is use, then erase better than just use?

sharptooth
  • 167,383
  • 100
  • 513
  • 979

5 Answers5

10

It does. Hibernation file is not encrypted, for example. And if you don't securely clear the memory, you might end up with trouble. It's just a single example, though. You should always hold secret stuff in memory only as long as needed.

Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
  • I understand that, but it's also possible that the password is copied into swapfile/hibernated when it is in use. What's the difference - the duration of storing it in memory? – sharptooth Apr 24 '09 at 14:39
  • 6
    Yes. you are reducing the attack surface. Remember: security is all about raising the bar. The more you raise the bar, the better. – Mehrdad Afshari Apr 24 '09 at 14:45
5

It exists for a reason. :) If you keep sensitive data in memory, then other processes can potentially read it.

Of course, in your application, passwords or other secure data may not be so critical that this is required. But in some applications, it's pretty essential that malicious code can't just snoop your passwords or credit card numbers or whatever other data the application uses.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • Why can't it snoop the data while the data is in use? Why "use, the erase" is better than just "use"? – sharptooth Apr 24 '09 at 14:46
  • 3
    Because "use, then erase" only leaves the data in memory for, let's say, a fraction of a second -- as opposed to "maybe until the application exits, maybe longer" (see answer above about the OS not zeroing memory). Malware would have to get much less lucky to find your data if it's in memory for a long time. – Joe White Apr 24 '09 at 14:53
4

Also note that it might be that some OS'es will not zero memory before giving it to an application, this means that an application might randomly request memory, scan it for possibly interesting content and do something with it.

If that application would only get zero'd memory, of course it would have a harder time trying to get interesting data.

Lennaert
  • 2,455
  • 15
  • 15
  • 4
    Windows does - see Russinovich & Solomon, Windows Internals, 4th Ed., Chap. 7 - Services the Memory Manager Provides, Reserving and Commiting Pages: "If the pages are private to the process and have never been accessed before, they are created at the time of first access as zero-initialized pages (or demand zero)." Not doing this would be a pretty big security hole (a process could read the stale from other processes). I'd be willing to bet that most modern operating systems do the same. – Michael Burr Apr 24 '09 at 19:28
3

SecureZeroMemory() will certainly not make your application perfectly secure. The fact that the password was already in memory is already a security hole. Using SecureZeroMemory() will definitely make it less likely that your password can be retrieved. I don't see any reason not to use it, so why not? Just remember that there are many other things you have to worry about too.

Zifre
  • 26,504
  • 11
  • 85
  • 105
3

If you actually have password data or other secrets, you're also going to want to make sure that the memory they are in doesn't get swapped out, otherwise the swap file can become a problem (I think the function you want is 'VirtualLock' for a windows app). Further you'll need to detect windows going into hibrenate and wipe the data at that point too. I believe Windows will send a message to every app when it's about to hibrenate.

Michael Kohne
  • 11,888
  • 3
  • 47
  • 79