Is explicitly clearing/zeroing sensitive variables after use sensible?

Question

I have noticed some programs explicitly zero sensitive memory allocations after use. For example, OpenSSL has a method to clear the memory occupied by an RSA key:

"Frees the RSA structure rsa. This function should always be used to free the RSA structure as it also frees sub-fields safely by clearing memory first."

http://www.rsa.com/products/bsafe/documentation/sslc251html/group__COMMON__RSA__KEY__FUNCS.html#aRSA_free

Where any (C/C++) program contains sensitive variables like this, should you explicitly zero the memory, as above? (Or, is zero'ing memory an act of paranoia or just a safeguard)?

Also, when a program finishes, any allocated memory is eventually allocated to another program. On a Linux system, is the memory cleaned or sanitised before being allocated to another program? Or, can the second program read some of the old memory contents of the first program?

Answer 1

On a Linux system, is the memory cleaned or sanitised before being allocated to another program?

Yes, on any respectable desktop OS, memory is sanitised when passed from a process to another. The cleaning step that you have observed is to protect from other attacks, from code executing in the same address space or obtaining privileges allowing it to read memory from the target process's memory space.

Where any (C/C++) program contains sensitive variables like this, should you explicitly zero the memory, as above?

It's a very sensible safeguard to erase this sensitive data as soon as you don't need it any more.

Answer 2

When programs/libraries like GPG and OpenSSL with sensitive cryptographic data explicitly zero memory, it has nothing to do with a fear that the memory will be "reassigned" to other programs which could read the data. This is fundamentally impossible due to the way multiprocess/multiuser operating systems work.

The reasons for zeroing data are twofold:

1. If the code is a library, you want to protect against careless information leakage by the calling program. Even though the memory that contained sensitive information cannot be reassigned to another process, freed memory can and will be reused in the same process as long as it's still running the same program image (i.e. as long as it hasn't called exec*). A buggy program might call malloc then write the buffer to disk without first filling the whole allocated object, in which case, old potentially-sensitive information could be leaked to disk. Issues of this kind exist in major real-world products like Microsoft Office (though they may have been fixed by now).

2. Even if the code is not a library but a stand-alone program, you may want to zero sensitive data in memory before freeing it for paranoia purposes. If the feds bust down your door and haul away your computer, they can subsequently examine whatever happened to be on the swap partitions. If they're careful in removing it they might even be able to examine ram contents. If you're paranoid about physical attacks, you want to ensure that passphrases, etc. do not exist anywhere in ram or on disk after they're used. Many cryptographic programs even want to have root access so they can mlockall their memory to prevent anything from getting swapped to disk (though in my view this is stupid - trading a serious risk of root compromise due to bugs in the software for paranoia about physical attack).

If you are not worried about physical attacks, or if you're sufficiently in touch with reality to realize that physical attackers probably have better ways of getting your passphrase than swap partition forensics, then reason #2 is probably mostly bogus, but most software addresses it anyway just to keep the nutcases happy. :-)

Answer 3

From a security standpoint, your memory might contain data that you would not like to linger around. If the process crashes and the core file will have the complete dump of the memory. It is possible to dig into those core files and mine data. For a support call, if you have to send that core file, you would feel safer if the memory is sanitized after use. When I worked on VMS, some sensitive customers would refrain from even giving us the dump files (making this extremely difficult to debug).