This is the mail archive of the
mailing list for the glibc project.
Re: malloc: Security implications of tcache
On Thu, Feb 08, 2018 at 07:23:14PM -0800, Carlos O'Donell wrote:
> All of the malloc security heuristics are *post attack* mitigations,
> the actual attack has already happened, and as Ondrej points out,
> the checks are already too late. The root cause should be addressed
> using other forms of formal analysis or prevention.
> Lastly, there is no conscious decision to remove security checks in
> any context, the existing contexts that have the checks have them
> still enabled, this is just *additional* code which has fewer checks
> because it handles chunks earlier and in a different structure.
As it reminded me my project of writting better malloc I have some more
First checks there were originally to debug malloc, checking is
Versus adversary they are mostly useless, it is relatively easy create
fake data structures in buffer to make all checks pass.
I plan to add checks that detects most overflows, basically like
valgrind but faster and it won't tell only that there was error,
not when error happened.
To detect overflows one could do lot stronger check thats faster than
existing checks. For data structures on both ends of allocated area
structure there will have checksum(for example xor entries xor randomly
generated guard) and both will be checked on free. For more strict
check add padding bytes at end to checksum computation.
To detect writes on freed memory its possible with similar slowdown as M_PERTURB.
M_PERTURB already does most work, on free set memory to given value and when its
allocated again check that there isn't other character. Malloc
datastructures in freed areas must be protected by checksum and clean up
back to given value.