On most operating systems memory owned by one process can be reused by another
vt-alt opened this issue · 5 comments
This looks like incorrect statement:
On most operating systems memory owned by one process can be reused by another without being cleared, either because the first process terminates or it gives back the memory to the system. If the memory contains secret keys these will be available to the second process, which increases the exposure of the key. On multiuser systems this can make it possible to sniff keys from other users. Even within a single system the increased exposure can cause previously harmless vulnerabilities to expose secret material. https://github.com/veorq/cryptocoding#problem-8
This is certainly not true for Linux and I bet for most other systems too.
You're right, this is incorrect as is, given for example https://stackoverflow.com/questions/6004816/kernel-zeroes-memory (HT @diagprov). Do you have a proposal of a better wording?
I need to re-read to see if we have covered elsewhere, but I would propose something like this:
On most modern operating systems, allocators do not always ask the kernel to free previously allocated memory, but make it available for reuse by the application at a later stage. If the memory contains secret keys that have not been cleared, these will remain available to read for longer than intended. The increased exposure can cause previously harmless vulnerabilities to expose secret material. On older or embedded systems, memory may not be cleared across 'process' boundaries leading to leaks of memory between these processes.
Wording I made up just now, can probably be improved.
I'll look into exactly what happens on Linux and Windows and make a PR unless someone beats me to it :) I did promise I'd do some maintenance work on this...
I think process memory can be unintentionally accessed by another process when — process is crashed and core dumped (by accessing the core file), process memory is swapped (by accessing swap partition), by exploiting a kernel bug or a bug in the process itself; or by some legitimate methods — such as process tracing[1].
ps. [1] ...or other debugging facilities. Also, hardware methods such as access via FireWire port, cold boot attack, memory freezing, etc.