You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to reduce the chance of an attacker reading sensitive memory or injecting data into memory that is either malicious code or could trigger code to run in a malicious way, we want to ensure that enclave memory is appropriately wiped.
As further context, improperly managed memory can expose attack vectors. This is particularly an issue in languages like C/C++ where it is always up to the author to implement memory managements. In the case of Rust, the compiler should handle memory management as long as unsafe Rust is not used. In other words the Rust compiler handles the details of memory allocation/deallocation and pointer management, which otherwise commonly cause bugs in languages like C/C++. (For reading on a real life example of memory abuse vectors check out https://blog.inhq.net/posts/u2fhid_init_resp-information-leak/).
Even though the Rust compiler implements memory management, we are not guaranteed that memory will be deallocating and wiped to zero. The compiler may choose not to deallocate and wipe memory for a variety reasons, likely the number 1 being performance: in some situations it may prefer to leave pages of memory if it speeds up execution does not change intended logic. For highly sensitive data, we will want to ensure zeroing does not get optimized away.
Strategy
To practically support this we want to look into building out QOS to support different types of memory wiping, but also expose libraries that enclave application developers can use to zero memory within the applications own logic.
Note that this issue tracks Rust specific approaches and may not be relevant for enclave apps written in other languages
emostov
changed the title
[Meta Issue] Zeroing memory and general secure memory management
[Meta] Zeroing memory and general secure memory management
Sep 20, 2022
@emostov: have there been any steps towards the action items since late 2022?
I know that we're using zeroize in qos_p256 and qos_client, plus indirectly via some of the Rust crypto libraries that use it. Beyond that, I don't think the situation has changed with regards to bigger forms of memory zeroing.
Context
In order to reduce the chance of an attacker reading sensitive memory or injecting data into memory that is either malicious code or could trigger code to run in a malicious way, we want to ensure that enclave memory is appropriately wiped.
As further context, improperly managed memory can expose attack vectors. This is particularly an issue in languages like C/C++ where it is always up to the author to implement memory managements. In the case of Rust, the compiler should handle memory management as long as unsafe Rust is not used. In other words the Rust compiler handles the details of memory allocation/deallocation and pointer management, which otherwise commonly cause bugs in languages like C/C++. (For reading on a real life example of memory abuse vectors check out https://blog.inhq.net/posts/u2fhid_init_resp-information-leak/).
Even though the Rust compiler implements memory management, we are not guaranteed that memory will be deallocating and wiped to zero. The compiler may choose not to deallocate and wipe memory for a variety reasons, likely the number 1 being performance: in some situations it may prefer to leave pages of memory if it speeds up execution does not change intended logic. For highly sensitive data, we will want to ensure zeroing does not get optimized away.
Strategy
To practically support this we want to look into building out QOS to support different types of memory wiping, but also expose libraries that enclave application developers can use to zero memory within the applications own logic.
Note that this issue tracks Rust specific approaches and may not be relevant for enclave apps written in other languages
Action Items
Short term
Medium term
Long term
Investigate: Wipe memory at startup with QOS bootloader #125
Investigate: Completely and programmatically reboot enclaves after sensitive operations #126
The text was updated successfully, but these errors were encountered: