Re: Deprecate mcheck?

[OndÅej BÃlka <neleai at seznam dot cz>]

On Mon, Feb 10, 2014 at 03:27:42PM +0100, Florian Weimer wrote:
> With -lmcheck, it is possible to add malloc checking hooks which
> wrap the allocations with an additional header.
> 
> The approach is not specific to our malloc implementation, it does
> not use internal implementation details (thus the separate header).
> The current implementation is not thread-safe and may be
> incompatible with early allocations in C++ code.  With help from the
> malloc implementation, it should be possible to come up with
> something that is quite a bit more efficient.
>
I suggested same thing here.

https://www.sourceware.org/ml/libc-alpha/2013-12/msg00552.html
 
You could in fact detect most invalid writes by following approach:

Each header will be protected by a checksum byte.
In chunk fill unused bytes by pseudorandom sequence. Before allocation
check that sequence and on free refill area with sequence. At end check
all chunks if sequences match. That will with probability 255/256 detect
invalid write of byte unless application first read these bytes stored
them somewhere else and restored them which is unlikely.

We could checksum headers and first 8 unused bytes by default which
would detect common errors better than current checks. A data checking
idea is similar to perturb_byte.

Comments?

> It's also odd that this functionality is enabled with -lmcheck or an
> explicit function call, and not with LD_PRELOAD (where it completely
> reside if necessary).
> 
> It also seems to me that it can't be abused as a security feature.
> The canaries are static, so the only secret is the heap
> randomization.  We also have something similar in glibc itself.
> 
> So I'd like to deprecate mcheck in 2.20, and remove -lmcheck in 2.21
> and turn the functions into hidden NOPs.
> 
> -- 
> Florian Weimer / Red Hat Product Security Team