This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: malloc: Security implications of tcache


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

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"

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:

- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]