search

veorq / cryptocoding

Guidelines for low-level cryptography software
1.11k stars 90 forks source link

On most operating systems memory owned by one process can be reused by another #23

Closed vt-alt closed 2 years ago

vt-alt commented 2 years ago

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.

veorq commented 2 years ago

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?

diagprov commented 2 years ago

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...

vt-alt commented 2 years ago

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.

veorq commented 2 years ago

Please go ahead and start a PR, better if it comes with links/references to back the claims.

On Fri, Jan 7, 2022 at 7:06 PM Vitalio @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/veorq/cryptocoding/issues/23#issuecomment-1007619066, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYONSTU2YBR4N4QWKPL773UU4TSLANCNFSM5LMWVIFQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

vt-alt commented 2 years ago

Because PR #24 was accepted I close this issue.