1

Sometimes passwords/hash/keys & other private information is stored in variables and hence in memory/RAM during code execution.

while some situations (i.e. Linux Kernels see here Is there any Linux distro or kernel patch that wipes a process memory space after the process exits? ) care about wiping used memory I was wondering more about the broader picture:

Question is therefore: Should the programmer of code care about wiping (i.e. zerosetting) sensitive information by her/himself? More precise should I do something like this

int main()
{
    char bufferWithSecret [10];
    sprintf (bufferWithSecret, "%d",generateKey());

    // do some stuff
    // ...
    // ...

    sprintf (bufferWithSecret, "000000000"); // wipe the memory
}
Improve this question

2 Answers 2

Reset to default
5

If you wipe sensitive information early, you might arguably reduce the time window for an exploit while your program is running, but in general (and in particular in a when-process-exits context) it's a pretty useless endeavor.

It's much more important to lock memory that contains sensitive data, so it cannot be swapped out. Sensitive data being swapped out is something you want to avoid at all cost.
The worst thing about a page with sensitive data being swapped out is, by the way, not even the fact that it's written to disk, but the fact that you cannot guarantee that it will ever be deleted from disk again (due to drives doing wear-levelling). This is totally out of control of the operating system, or even your application.

Memory pages are zeroed before being handed to a new process on every non-joke operating system, so zeroing them manually does not really add anything (not on a realistic threat model, anyway).
Of course someone might use a DMA exploit (such as Firewire) to read physical RAM pages that have not been cleared, but they could already do that while your program is running, insofar not much is gained by erasing them a little earlier.

Improve this answer
4
  • my joke operation system/setting is called one of the many JavaScript engine implementations. With all the GC and caching and optimization I am unsure if the "OS" cleares memory principles applies. Therefore I assumed that there are joke OS/situation and hence to be sure the step to wipe sensitive data is a recomended best practise step, just in case. Thanks for the insights of the answer.
    – humanityANDpeace
    Apr 24, 2014 at 11:14
  • @humanityANDpeace: The OS will clear the memory before giving it to another process, however a browser's JavaScript engine might easily reuse memory for another script without it being returned to the OS meanwhile, and therefore clearing the memory to prevent cross-site disclosure is a good idea. On the other hand, Javascript shouldn't be allowing read of uninitialized variables in the first place. This is more a problem for unmanaged languages.
    – Ben Voigt
    May 1, 2014 at 20:03
  • 1
    I still somewhat disagree with your answer. Security is all about defense in depth; wiping secrets from memory as soon as is feasible can dramatically reduce the real-world impact of vulnerabilities like memory leaks (e.g., Heartbleed).
    – Stephen Touset
    May 1, 2014 at 20:14
  • @BenVoigt But the OS will not clear the memory on process destruction or munmap(), so just because a correctly behaving kernel will initialize the memory does not mean it will actually be wiped, opening up room for other bugs. This is the reason grsecurity clears this memory when returning to the kernel when cleaning up process resources, and the reason why OpenBSD's libc poisons values on free().
    – forest
    Dec 31, 2017 at 5:56
1

No you should not do something "like that". You should use a library function which is intended for wiping sensitive data.

The problem with using general-purpose routines such as sprintf, memset, or your own loop is that the compiler may perform data dependency analysis, determine that the new value is unimportant, and optimize away the write.

Windows provides a SecureZeroMemory function for exactly this reason. Some frameworks make this very easy, others not at all. You might check this question for more information:

Finally, SecureZeroMemory and .NET SecureString only exist because this IS a good practice.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .