This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc: Security implications of tcache
Hi,
On 02/10/2018 07:23 AM, Ondřej Bílka wrote:
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.
This is not true. The checks are designed against simple overflows or
bad-frees and should prevent an attacker to utilize the heap internal
operations to leverage these simple primitive to actual attacks, which
potentially result in code execution.
I'm not saying that a heap implementation necessarily has to protect an
application in that way, but glibc heap certainly tries to and saying
the tcache is not a problem because security was not a concern before
and all the efforts were just for debugging/"post attack" is not true IMHO.
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.
Yes, that is exactly the point, the checks still exist, but are totally
pointless now, as an attacker can just omit the completely by staying in
the tcache layer.
As it reminded me my project of writting better malloc I have some
more comments.
First checks there were originally to debug malloc, checking is
secondary. Versus adversary they are mostly useless, it is relatively
easy create fake data structures in buffer to make all checks pass.
This is not true. The "mcheck" option was designed for debugging, the
checks in malloc/free are actually designed to prevent exploitation in
practice as I pointed out above.
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.
A heap-cookie could be a useful addition, but I'm not pointing out flaws
with the original checks with my email, but the effect the tcache has on
their effectiveness.
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.
Similar, these could be useful changes/additions, but this is not the
problem I'm pointing at with the tcache.
- If you have serious security concerns over tcache and have
proof of concept exploits and would like to disclose, please
follow the "Security Process"
https://sourceware.org/glibc/wiki/Security%20Process
There is already some public debate about this going in channels like
twitter and somebody wrote a a blog post how the tcache is affecting
known attacks: http://tukan.farm/2017/07/08/tcache/
- If you are analyzing the security of tcache we would love to
hear constructive feedback, suggestions, and patches to fix
any issues.
We're indeed doing on-going research in this direction, which I'm
willing to share here as soon as it is public.
With my initial mail, I just wanted to figure out if people here are
aware what the implications of the tcache in regards of security are and
assuming what lead to the decision to step back from security with this
addition.
Thanks
Moritz