[alexfoo]

> Now, if the attacker has an off-by-one corruption with a small value (NUL or \x01 - \x07) that hits the lowest significant byte of a length (malloc_chunk->size), the attacker can only use that to cause the length to effectively shrink. This is because all heap chunks are at least 8 bytes under the covers. Shrinking a chunk's length means it will never match the prev_size stored at the end of that chunk. Even if the attacker deploys their one byte overflow multiple times, this new check should always catch them.

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.

[scarybeast]

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.

[alexfoo]

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.

[damienkatz]

That part also confuses me.