diff options
author | Eyal Itkin <eyalit@checkpoint.com> | 2020-03-20 21:19:17 +0200 |
---|---|---|
committer | Carlos O'Donell <carlos@redhat.com> | 2020-03-29 13:03:14 -0400 |
commit | a1a486d70ebcc47a686ff5846875eacad0940e41 (patch) | |
tree | cb62693a8c32deed5443fd79ef62707792d03e2d /bits | |
parent | 642d5abaf11b033a1bfc88fd66f736f61a3fd17b (diff) | |
download | glibc-a1a486d70ebcc47a686ff5846875eacad0940e41.tar.gz glibc-a1a486d70ebcc47a686ff5846875eacad0940e41.tar.xz glibc-a1a486d70ebcc47a686ff5846875eacad0940e41.zip |
Add Safe-Linking to fastbins and tcache
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 "next" 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 2012, and according to their documentation it had an overhead of less than 2%. Reviewed-by: DJ Delorie <dj@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Adhemerval Zacnella <adhemerval.zanella@linaro.org>
Diffstat (limited to 'bits')
0 files changed, 0 insertions, 0 deletions