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

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

It took some time, but I signed all the forms, and just received back
the mutually signed FSF form.

What is needed now in order to proceed with the patch that I've submitted?

Thanks again for your cooperation,
Eyal Itkin.


On Mon, 3 Feb 2020, 21:47 Eyal Itkin, <eyal.itkin@gmail.com> wrote:
>
> 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.
> >