Potential security issues in mimalloc-secure

Nobody has claimed this yet.

Hi! @ironore15 and I are working for research on secure allocators.

During research, we have found several potential security issues in mimalloc-secure mode.
We want to get your feedback regarding these issue.s

- Metadata leakage

We found that metadata can be leaked even in secure mode.

Here is the proof of concept code.
```c
#include
#include

int main(void) {
void *p1 = malloc(32); // prevent calling mi_segment_free
void *p2 = malloc(64); // page with xblock_size = 64
free(p2); // calling _mi_page_retire
void *p3 = malloc(-8); // trigger mi_heap_collect with MI_FORCE
void *p4 = malloc(128); // alloc page with same page_area
fprintf(stderr, "%p\n", ((void **)p4)[8]);
}
```

If we run the code in Ubuntu 18.04, it shows like this.
```sh
$ LD_PRELOAD=./libmimalloc-secure.so ./test
0x41cb4a160092279d
````

As you can see, `((void **)p4)[8]` contains encoded metadata of mimalloc heap.
We believe that it breaks your attempt to [remove internal data in secure mode](https://github.com/microsoft/mimalloc/blob/92ead2d88061dde1264800b389b744ac1b79cf39/src/alloc.c#L39).

It happens because `_mi_page_free` doesn't remove metadata of free_list. In the above PoC, when we call malloc(-8), which is huge page, mimalloc calls `_mi_page_free` to reclaim used pages. A page with `xblock_size=64` from `p2` is also one of reclaimed pages. Then, the next malloc(128) will reuse the previous page, which contains an encoded free_list.

I think one way to fix this issue is that we can zero-out page in secure mode.

- Heap spray

In mimalloc-secure mode, an attacker can allocate a fixed memory address and bypass ASLR.
Here is PoC code.
```c
#include
#include
int main(void) {
void *p = malloc(0x40000000000);
*(int *)0x7FFFFFFF000 = 0;
return 0;
}
```

This always exit successfully without segmentation fault.

It happens because eager commit option and mmap with aligned hint address. When segment is initially allocated, it calls `_mi_mem_alloc_aligned`. On UNIX system, it internally calls `mi_unix_mmapx` with addr is NULL, and `mi_os_get_aligned_hint` to get address for segment. In the following the [code](https://github.com/microsoft/mimalloc/blob/92ead2d88061dde1264800b389b744ac1b79cf39/src/os.c#L477), (1 << 42) ~ (1 << 43) are only valid segment address. Since [Eager commit](https://github.com/microsoft/mimalloc/blob/92ead2d88061dde1264800b389b744ac1b79cf39/src/options.c#L69) is enabled default, very large allocation, e.g., `malloc(1 << 42)`, will always alloc memory address between 0x7FFFFFFF000 ~ 0x80000000000.

We believe that one easy way to mitigate this is to disable eager commit in secure mode.
But I am not sure that it fits with mimalloc's design descision.

Best,
Insu Yun

Start by reproducing the supplied C PoCs on the reported Ubuntu setup, including the secure library preload. Read the referenced paths in src/alloc.c, src/os.c, and src/options.c to trace page reclamation, aligned mapping, and eager commit. Done requires an agreed mitigation for both reported behaviors and validation that the PoCs no longer demonstrate them.

Written by the indexing model from the issue text.