4 ms·

> This single overflow check could very well be the difference between denial-of-service-via-OOM and heap overflow OOM in general cannot be used for remote cod

by foxhill 12y ago

> This single overflow check could very well be the difference between denial-of-service-via-OOM and heap overflow OOM in general cannot be used for remote code execution. heap overflow can. > Should we then abandon ASLR or PIE or other defensive measures as well, just because some code is "already in trouble" due to a bad strcpy or something similar certainly not, ASLR is so general that it doesn't make sense to not do it. more importantly, they're entirely transparent to the programmer, and can be used on existing codes.

dezgeg 12y ago
> OOM in general cannot be used for remote code execution. heap overflow can. That was exactly my point. Using reallocarray() instead of malloc(x * sizeof(foo)) can prevent a heap overflow bug. For a concrete example (assuming 32-bit size_t): size_t user_input = ...; size_t* ptr = malloc(user_input * sizeof(size_t)); if (!ptr) return "FAIL: Out of memory"; for (size_t i = 0; i < user_input; i++) ptr[i] = whatever(); Now, a user_input of 2^30 + 1 overflows the multiplication so only 4 bytes is allocated, and then the for loop causes a heap overflow. Boom. But if the code was this: size_t user_input = ...; size_t* ptr = reallocarray(NULL, user_input, sizeof(size_t)); if (!ptr) return "FAIL: Out of memory"; for (size_t i = 0; i < user_input; i++) ptr[i] = whatever(); Now, a user_input of 2^30 + 1 would cause reallocarray() to return NULL, and the function returns. Heap overflow avoided by using reallocarray(). Of course, that code is still somewhat bad, since a user_input of 2^30 - 1 will cause the program to use large amounts for memory.
- foxhill 12y ago
  yes, i understand. as you correctly state, user input of 2^30 is.. well, it's unlikely. more likely, is a user being able cause a program to do billions of reallocs. in which case, OOM is going to happen before overflow and exploitation.

by foxhill 12y ago

dezgeg 12y ago

> OOM in general cannot be used for remote code execution. heap overflow can. That was exactly my point. Using reallocarray() instead of malloc(x * sizeof(foo)) can prevent a heap overflow bug. For a concrete example (assuming 32-bit size_t): size_t user_input = ...; size_t* ptr = malloc(user_input * sizeof(size_t)); if (!ptr) return "FAIL: Out of memory"; for (size_t i = 0; i < user_input; i++) ptr[i] = whatever(); Now, a user_input of 2^30 + 1 overflows the multiplication so only 4 bytes is allocated, and then the for loop causes a heap overflow. Boom. But if the code was this: size_t user_input = ...; size_t* ptr = reallocarray(NULL, user_input, sizeof(size_t)); if (!ptr) return "FAIL: Out of memory"; for (size_t i = 0; i < user_input; i++) ptr[i] = whatever(); Now, a user_input of 2^30 + 1 would cause reallocarray() to return NULL, and the function returns. Heap overflow avoided by using reallocarray(). Of course, that code is still somewhat bad, since a user_input of 2^30 - 1 will cause the program to use large amounts for memory.

foxhill 12y ago
yes, i understand. as you correctly state, user input of 2^30 is.. well, it's unlikely. more likely, is a user being able cause a program to do billions of reallocs. in which case, OOM is going to happen before overflow and exploitation.