Re: malloc: Security implications of tcache

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

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.