malloc: Security implications of tcache

malloc: Security implications of tcache

[Moritz Eckert]

Hey,

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?

Thank you,
Moritz

Re: malloc: Security implications of tcache

[Ondřej Bílka]

On Thu, Feb 08, 2018 at 01:31:45PM -0800, Moritz Eckert wrote:
> Hey,
> 
> I was wondering if people are aware of the security implications of
> the tcache structure?

Thats pointless, as checks are there just to help developers fix their
errors, nothing more. 

It couldn't prevent anything, attacker could just overwrite pointers of
  user applications for same effect instead relying on this.

Re: malloc: Security implications of tcache

[Carlos O'Donell]

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.

Re: malloc: Security implications of tcache

[Ondřej Bílka]

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

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.

Re: malloc: Security implications of tcache

[Moritz Eckert]

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

Re: malloc: Security implications of tcache

[Carlos O'Donell]

On 02/14/2018 03:36 PM, Moritz Eckert wrote:
> 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.

The efforts have always been post attack mitigation.

The real attack is the buffer overflow and the damage it can do to the
internal state of the program.

Again I want to be clear that we are talking explicitly about post attack
mitigation.

Therefore in this context we are talking about hardening tcache in
a post-attack mitigation to prevent buffer overflows from corrupting
chunk data.

It *is* important for us to try to prevent tcache from being used to
craft exploits, but we will balance this against performance, particularly
since this is a post-attack mitigation.
 
>>> 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.

The checks are not pointless, they remain valid for chunks not in tcache,
which depends on your usage.

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

Thanks for that link.
 
>> - 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.

That is exciting! I'm always happy to engage with researchers on the
topic, and glad to see you reaching out to upstream.

-- 
Cheers,
Carlos.