Re: malloc: Security implications of tcache

[Carlos O'Donell <carlos at redhat dot com>]

On 02/08/2018 01:31 PM, Moritz Eckert wrote:
> I was wondering if people are aware of the security implications of
> the tcache structure?
> 
> Itis operating in similar fashion to the fastbin free-list, but
> without any security checks at all to detect memory corruptions. This
> leads back to unconstrained writes and unconstrained arbitrary
> allocations, similar to the times of dlmalloc. Eventually, this makes
> all the security checks introduced before rather pointless, as they
> are bypassed completely by design.
> 
> There is no real fix to this problem, apart from disabling the tcache
> of course, so I was wondering what lead to the decision to remove
> security checks in this context?

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.

There are still several checks in the free() path, even with
tcache enabled. The cache is integrated directly into the bin sorting
algorithm in free, and so you have:
* invalid pointer check.
* invalid size check.
* chunk in use assertions.
all before you get to tcache_put.
Many of the subsequent checks don't apply to tcache because it
doesn't have any linked list structure that can get corrupted.

In summary:

- 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

- If you are analyzing the security of tcache we would love to
  hear constructive feedback, suggestions, and patches to fix
  any issues.

-- 
Cheers,
Carlos.