ssrg-vt / slimguard Goto Github PK

Mimalloc's test-stress is a multi-threaded microbenchmark for memory allocators. Its default configuration fails to run with SlimGuard. To reproduce the issue, see the make run target here:

make run
gcc -g test-stress.c -o test-stress -lpthread
LD_PRELOAD=/home/pierre/Desktop/SlimGuard/test/mimalloc/../../libSlimGuard.so ./test-stress
Using 32 threads with a 10% load-per-thread and 50 iterations
- iterations left:  40
- iterations left:  30
- iterations left:  20
Segmentation fault
make: *** [Makefile:13: run] Error 139

See this test: https://github.com/ssrg-vt/SlimGuard/blob/master/test/memalign.c

./memalign
# ...
Required alignment 0x2000 got pointer @0x7f7c44b95000

I use glibc 2.35 on my system, and i can't compile libSlimGuard, because of the symbols used in src/gnuwrapper.cpp.
These symbols (__malloc_hook, etc) are not found by my compiler, because they have been removed from glibc.

From glibc 2.34 log :

• The deprecated memory allocation hooks __malloc_hook, __realloc_hook,
  __memalign_hook and __free_hook are now removed from the API. Compatibility
  symbols are present to support legacy programs but new applications can no
  longer link to these symbols. These hooks no longer have any effect on glibc
  functionality. The malloc debugging DSO libc_malloc_debug.so currently
  supports hooks and can be preloaded to get this functionality back for older
  programs. However this is a transitional measure and may be removed in a
  future release of the GNU C Library. Users may port away from these hooks by
  writing and preloading their own malloc interposition library.

Just wanted to let you know

On a CentOS Linux release 7.8.2003 (Core), I'm experiencing the following error with any binary when trying to use SlimGuard:
ls: mmap(8589934592): Cannot allocate memory
ls: Cannot allocate class 3 data area

As a matter of fact, this is experienced using the simplest mode:
LD_PRELOAD=/path/to/libSlimGuard.so /your/app

The class number depends on the binary used:
cat: mmap(8589934592): Cannot allocate memory
cat: Cannot allocate class 1 data area

a.out: mmap(8589934592): Cannot allocate memory
a.out: Cannot allocate class 162 data area

We (I and @ironore15) According to our evaluation, SlimGuard's invalid check is insufficient.
Is it bug? or just design issue?

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <malloc.h>

void* p[256];
uintptr_t buf[256];

int main() {
  buf[119] = 48;
  fprintf(stderr, "%p\n", buf[121]);
  free(&buf[120]);
  fprintf(stderr, "%p\n", buf[121]);
}

LD_PRELOAD=$(pwd)/libSlimGuard.so ./poc
(nil)
0x7fda100008d0

Best,
Insu Yun.

The seed is set here:
https://github.com/ssrg-vt/SlimGuard/blob/master/src/slimguard.c#L101

If an attacker has control over the return value of time(), it could set it to 0, which will make that all canaries will have a value of 0.

We need a good RNG integrated within SlimGuard's code.

See this test case: https://github.com/ssrg-vt/SlimGuard/blob/master/test/memalign-free.c

./memalign-free
free(): invalid pointer

To reproduce see the test memalign. Enable guard pages and we get a segfault for an allocation of size 32768 (8 pages). The allocated buffer spans a guard page.

Hi.

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <malloc.h>

void* p[256];
uintptr_t buf[256];

int main() {
  p[0] = malloc(-8);
  fprintf(stderr, "%p\n", p[0]);
}

This program will crash if we run it with SlimGuard.
The reason is that SlimGuard checks mark_used without validating the return value from previous call, which could be zero( https://github.com/ssrg-vt/SlimGuard/blob/master/src/slimguard.c#L409)

Best,
Insu Yun.

I am trying to understand the behaviour of Slimguard during the memory allocations and freeing, but something seems strange. When I requested addresses with a malloc call, for instance 10 of them, and freed them juste after (whatever value I put inside, and having some values used before so that the memory page is not release with madvise), the 10 next addresses given by malloc seemed to be exactly the same.

In the sources, at this line, if I am not mistaken the if is true if there are at least 2 values in the free list (head and next of the head not null). Therefore when calling for memory, if the list is composed of 10 previously freed addresses (by this line) then 10 of them are returned in the inverted order of their freeing. I read your research-article of this library and it doesn't exactly suggests the same implementation of the free list, with in the implementation a bucket where we take random values from and a free list where the newly freed values are without randomization. Did I misunderstand the implementation/objective or is there really a problem of use-after-free possibilities ?

See the make run target here:

make run
gcc -g malloc-test.c -o malloc-test -lpthread
LD_PRELOAD=/home/pierre/Desktop/SlimGuard/test/malloc-test/../../libSlimGuard.so ./malloc-test 100000 1048576
Segmentation fault
make: *** [Makefile:13: run] Error 139