Detect out-of-bounds reads

[Shnatsel]

It would be nice to be able to detect out-of-bounds reads as well. This is actually pretty easy to implement - just allocate more memory than was requested and clobber it with the same variable value as the rest of the buffer. If any of the clobbered values show up in the output, then the program is definitely exploitable - either via reads from uninitialized memory or via out-of-bounds reads.

Use case: I needed this functionality to determine whether sile/libflate#16 is exploitable or not.

I have already implemented checks for out-of-bounds reads to the right of the buffer in branch detect-oob-reads, but the ones to the left are still TODO - there's just a static canary there that's inherited from libdislocator.

[PlasmaPower]

Doesn't the additional mprotect page already do this?

[PlasmaPower]

I guess that's also missing for calloc.

[Shnatsel]

Additional mprotect page makes the program crash, which sort of works, but muddles the picture because you can't tell if it was an out-of-bounds write or an information leak.

I find that tools tools complementary to each other work best, and the more approaches you have in your toolbox, the better. The mprotect page is not terribly useful because libdislocator and Address Sanitizer already detect the exact same thing, so I'm trying to do something complementary here.

In my use case I had a program crash under libdislocator (with mprotect page), and wanted to run it through a different tool to determine whether this is an actually exploitable out-of-bounds read. ASAN would also report the error regardless. So I've tweaked libdiffuzz to allocate extra space at the end and clobber it, which is an approach orthogonal to existing tools, and that gave me the answer I was looking for.

Good point about calloc!

[Shnatsel]

#4 has added an option to detect OOB reads that come after the allocated buffer. It is toggled by an environment variable. OOB reads from before the allocated buffer are not yet detected.