Heap Areas not Zeroed when (De)allocated

[lrapp-x41-pub]

A heap area is not zeroed when allocated, neither when deallocated. Data written to the heap will stay there until it is overwritten again. Thus, it is possible to allocate an area on the heap and read out whatever was written there before. This could lead to disclosure of sensitive information.

[jbreitbart]

Can you provide some information on why you think this should be done in a unikernel? After all, there is just one application running and there is also no isolation mechanism that would allow you to run untrusted code at the moment.

Is the behavior different if you call new/free multiple times within a standard C application on Linux? Is a memory region reset to zero even if the page is not returned to the kernel?

[lrapp-x41-pub]

To clarify this: This is not a vulnerability, nor a must-have security feature, but an additional security hardening feature.

The relevant scenario here is not necessarily untrusted code running, but a vulnerable application, which allows an attacker to read allocated, but uninitialized memory (e.g. an application that allocates a variable on the heap and reflects the allocated, but uninitialized variable's content back to the user, out-of-bounds read, etc). This can be a relevant threat in scenarios where multiple users interact with the unikernel, e.g. when using an API build upon the unikernel.

With C on Linux, one can use calloc to allocate memory which is set to 0. Alternatively, on can set the M_PERTURB parameter to overwrite the memory when it gets allocated or freed. This takes effect when allocating memory areas above a certain size, probably due to performance considerations.

So in my opinion it would make sense to have this as an optional security hardening feature for users who demand a high level of security and / or work with sensitive user data.

[lrapp-x41-pub]

After discussing this with @jounathaen and @stlankes the following questions came up: Is there any way to tell Rust to clean memory on allocation or free when using data structures like Box or Vec? If there is not, it should be evaluated how to implement an optional flag to clean heap memory on allocation / free in RustyHermit. As already explained above, this is just an additional security hardening feature, other aspects are of higher priority.