Re: [PATCH] Add Safe-Linking to fastbins and tcache

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

On 2/2/20 4:43 AM, Eyal Itkin wrote:
> Safe-Linking is a security mechanism that protects single-linked
> lists (such as the fastbin and tcache) from being tampered by attackers.
> The mechanism makes use of randomness from ASLR (mmap_base), and
> when combined with chunk alignment integrity checks, it protects the
> pointers from being hijacked by an attacker.
> 
> While Safe-Unlinking protects double-linked lists (such as the small
> bins), there wasn't any similar protection for attacks against
> single-linked lists. This solution protects against 3 common attacks:
>   * Partial pointer override: modifies the lower bytes (Little Endian)
>   * Full pointer override: hijacks the pointer to an attacker's location
>   * Unaligned chunks: pointing the list to an unaligned address
> 
> The design assumes an attacker doesn't know where the heap is located,
> and uses the ASLR randomness to "sign" the single-linked pointers. We
> mark the pointer as P and the location in which it is stored as L, and
> the calculation will be:
>   * PROTECT(P) := (L >> PAGE_SHIFT) XOR (P)
>   * *L = PROTECT(P)
> 
> This way, the random bits from the address L (which start at the bit
> in the PAGE_SHIFT position), will be merged with LSB of the stored
> protected pointer. This protection layer prevents an attacker from
> modifying the pointer into a controlled value.
> 
> An additional check that the chunks are MALLOC_ALIGNed adds an
> important layer:
>   * Attackers can't point to illegal (unaligned) memory addresses
>   * Attackers must guess correctly the alignment bits
> 
> On standard 32 bit Linux machines, an attack will directly fail 7
> out of 8 times, and on 64 bit machines it will fail 15 out of 16
> times.
> 
> This proposed patch was benchmarked and it's effect on the overall
> performance of the heap was negligible and couldn't be distinguished
> from the default variance between tests on the vanilla version. A
> similar protection was added to Chromium's version of TCMalloc
> in 2013, and according to their documentation it had an overhead of
> less than 2%.
> 
> For more information, please read out White Paper which can be
> found here:
> https://github.com/gperftools/gperftools/files/4023520/Safe-Linking-White-Paper.txt

The concept behind your patch looks really interesting, thank you for
working on this patch!

One of the things we'll need from you is a copyright assignment
before the glibc project can accept the patches.

Please have a look at our "Contribution Checklist"
https://sourceware.org/glibc/wiki/Contribution%20checklist

"FSF Copyright Assignment"
https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment

I always suggest a futures assignment so we can accept this patch
and all future patches you submit to glibc:
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future

Thank you for your contribution!

-- 
Cheers,
Carlos.