Openenclave: Heap Data Measurement
According to Intel, MRENCLAVE value consists of:
- The contents of the pages (code, data, stack, heap).
- The relative position of the pages in the enclave.
- Any security flags associated with the pages.
It seems OpenEnclave does not include heap page contents in the MRENCLAVE value. What is the reason for this design choice?
eozturk1
All 6 comments
Hello @eozturk1. Thank you for reporting this issue. It represents an attack vector for programs that fail to correctly initialize memory after obtaining it from the heap. Please see notes below.
Both Intel and Microsoft decided not to measure the heap pages in their respective SDKs. A correct, well-behaved program will never read from the initial heap page contents. However, programs that fail to properly initialize memory returned from sbrk, malloc, and realloc are potentially vulnerable to attack. So this attack vector should be addressed. But how?
Measuring the pages on enclave load is a non-starter since the heap can be much larger than the EPC memory. For example, an enclave can have 16GB of heap space while the total EPC memory might be 128MB. Measuring heap pages would result in extreme thrashing during loading (due to swapping). That is probably why Intel decided not to measure heap pages.
One solution is to zero initialize all memory obtained from sbrk but only when it results in a new high. Since dlmalloc is based solely on sbrk, this will incrementally initialize heap memory on demand. This solution trades off performance for security.
mikbras
on 17 Dec 2019
I created the following PR to address this issue:
https://github.com/openenclave/openenclave/pull/2383
It ensures that all memory obtained with oe_sbrk() and hencse malloc and realloc will be zero filled.
mikbras
on 17 Dec 2019
Thank you for looking into this @mikbras! Interesting to see the documentation does not match the implementation on Intel's end. Can you please close the issue when the PR is merged?
eozturk1
on 18 Dec 2019
Tooling to catch use of uninitialized memory may be better.
jhand2
on 7 Jan 2020
@mikbras Hi Mike, are you sure about your characterization in the initial reply? https://github.com/openenclave/openenclave/issues/2373#issuecomment-566306591
They way I understand the reason to not extend the heap page measurements is that the pages are set to 0 before they are added. This is a performance enhancement without a security risk given that the pages are filled with zero.
douglasism
on 6 Feb 2020
As @douglasism pointed out, the heap pages are all zero'd by the loader.
Closing this issue, please reopen if you feel the issue is still relevant.
jhand2
on 6 Feb 2020
Related issues
manojrupireddy
路
6Comments
mingweishih
路
7Comments
jhand2
路
3Comments
maverick-zhn
路
7Comments
Lusitanian
路
8Comments
Most helpful comment
Hello @eozturk1. Thank you for reporting this issue. It represents an attack vector for programs that fail to correctly initialize memory after obtaining it from the heap. Please see notes below.
Both Intel and Microsoft decided not to measure the heap pages in their respective SDKs. A correct, well-behaved program will never read from the initial heap page contents. However, programs that fail to properly initialize memory returned from sbrk, malloc, and realloc are potentially vulnerable to attack. So this attack vector should be addressed. But how?
Measuring the pages on enclave load is a non-starter since the heap can be much larger than the EPC memory. For example, an enclave can have 16GB of heap space while the total EPC memory might be 128MB. Measuring heap pages would result in extreme thrashing during loading (due to swapping). That is probably why Intel decided not to measure heap pages.
One solution is to zero initialize all memory obtained from sbrk but only when it results in a new high. Since dlmalloc is based solely on sbrk, this will incrementally initialize heap memory on demand. This solution trades off performance for security.