Re:Further hardening glibc malloc() against single byte over...
by scarybeast on Thursday May 18, 2017 @03:26AM
(#14365428)
Yeah, good question.
The lower bits of ->size are actually masked off when considering a chunk's size, because they are flags:
#define SIZE_BITS (PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
/* Get size, ignoring use bits */ #define chunksize(p) ((p)->size & ~(SIZE_BITS))
So you really can't increase the size by less than 8. However, I know what you're now thinking: an attacker with a 1-byte overflow can mess with the flags! That would be a topic for another blog post, but I'm not aware of any techniques where messing with the flags would permit a clean ASLR bypass.
Re:Further hardening glibc malloc() against single byte over...
by alexfoo on Thursday May 18, 2017 @04:58AM
(#14365776)
Ah, good point.
From: https://sploitfun.wordpress.com/2015/02/10/understanding-gli...
Last 3 bits of this field contains flag information.
PREV_INUSE (P) – This bit is set when previous chunk is allocated.
IS_MMAPPED (M) – This bit is set when chunk is mmap’d.
NON_MAIN_ARENA (N) – This bit is set when this chunk belongs to a thread arena.
It certainly doesn't look like those could be used against ASLR.
Re:Further hardening glibc malloc() against single byte over...
by damienkatz on Thursday May 18, 2017 @03:08AM
(#14365366)
That part also confuses me.
Is the LSB of the heap chunk size always >= 8?
What about a malloc_chunk->size with a multiple of 256? (Or anything else with an LSB < 7). With a one byte overflow one of this they could cause it to think that the size is up to 7 bytes more than the size of the real chunk.