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

[Eyal Itkin <eyal dot itkin at gmail dot com>]

Thanks for your fast response.
I've just sent an assignment using your supplied form.

If anything else is needed I will be more than happy to assist.

Eyal.

On Mon, Feb 3, 2020 at 8:10 PM Carlos O'Donell <codonell@redhat.com> wrote:
>
> 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.
>