lkml.org 
[lkml]   [2020]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH RFC 0/2] Break heap spraying needed for exploiting use-after-free
    From
    Date
    On 13.08.2020 18:19, Alexander Popov wrote:
    > Hello everyone! Requesting for your comments.
    >
    > Use-after-free vulnerabilities in the Linux kernel are very popular for
    > exploitation. A few examples:
    > https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html
    > https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html?m=1
    > https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html
    >
    > Use-after-free exploits usually employ heap spraying technique.
    > Generally it aims to put controlled bytes at a predetermined memory
    > location on the heap. Heap spraying for exploiting use-after-free in
    > the Linux kernel relies on the fact that on kmalloc(), the slab allocator
    > returns the address of the memory that was recently freed. So allocating
    > a kernel object with the same size and controlled contents allows
    > overwriting the vulnerable freed object.
    >
    > I've found an easy way to break heap spraying for use-after-free
    > exploitation. I simply extracted slab freelist quarantine from KASAN
    > functionality and called it CONFIG_SLAB_QUARANTINE. Please see patch 1.
    >
    > If this feature is enabled, freed allocations are stored in the quarantine
    > and can't be instantly reallocated and overwritten by the exploit
    > performing heap spraying.
    >
    > In patch 2 you can see the lkdtm test showing how CONFIG_SLAB_QUARANTINE
    > prevents immediate reallocation of a freed heap object.
    >
    > I tested this patch series both for CONFIG_SLUB and CONFIG_SLAB.
    >
    > CONFIG_SLAB_QUARANTINE disabled:
    > # echo HEAP_SPRAY > /sys/kernel/debug/provoke-crash/DIRECT
    > lkdtm: Performing direct entry HEAP_SPRAY
    > lkdtm: Performing heap spraying...
    > lkdtm: attempt 0: spray alloc addr 00000000f8699c7d vs freed addr 00000000f8699c7d
    > lkdtm: freed addr is reallocated!
    > lkdtm: FAIL! Heap spraying succeed :(
    >
    > CONFIG_SLAB_QUARANTINE enabled:
    > # echo HEAP_SPRAY > /sys/kernel/debug/provoke-crash/DIRECT
    > lkdtm: Performing direct entry HEAP_SPRAY
    > lkdtm: Performing heap spraying...
    > lkdtm: attempt 0: spray alloc addr 000000009cafb63f vs freed addr 00000000173cce94
    > lkdtm: attempt 1: spray alloc addr 000000003096911f vs freed addr 00000000173cce94
    > lkdtm: attempt 2: spray alloc addr 00000000da60d755 vs freed addr 00000000173cce94
    > lkdtm: attempt 3: spray alloc addr 000000000b415070 vs freed addr 00000000173cce94
    > ...
    > lkdtm: attempt 126: spray alloc addr 00000000e80ef807 vs freed addr 00000000173cce94
    > lkdtm: attempt 127: spray alloc addr 00000000398fe535 vs freed addr 00000000173cce94
    > lkdtm: OK! Heap spraying hasn't succeed :)
    >
    > I did a brief performance evaluation of this feature.
    >
    > 1. Memory consumption. KASAN quarantine uses 1/32 of the memory.
    > CONFIG_SLAB_QUARANTINE disabled:
    > # free -m
    > total used free shared buff/cache available
    > Mem: 1987 39 1862 10 86 1907
    > Swap: 0 0 0
    > CONFIG_SLAB_QUARANTINE enabled:
    > # free -m
    > total used free shared buff/cache available
    > Mem: 1987 140 1760 10 87 1805
    > Swap: 0 0 0
    >
    > 2. Performance penalty. I used `hackbench -s 256 -l 200 -g 15 -f 25 -P`.
    > CONFIG_SLAB_QUARANTINE disabled (x86_64, CONFIG_SLUB):
    > Times: 3.088, 3.103, 3.068, 3.103, 3.107
    > Mean: 3.0938
    > Standard deviation: 0.0144
    > CONFIG_SLAB_QUARANTINE enabled (x86_64, CONFIG_SLUB):
    > Times: 3.303, 3.329, 3.356, 3.314, 3.292
    > Mean: 3.3188 (+7.3%)
    > Standard deviation: 0.0223
    >
    > I would appreciate your feedback!

    While waiting for the feedback on these RFC patches, I compiled a list of topics
    for further research:

    - Possible ways to overwrite a quarantined heap object by making a large amount
    of allocations (with/without freeing them)

    - How init_on_free=1 affects heap spraying on a system with the heap quarantine

    - How releasing batches of quarantine objects right away affects heap spraying
    reliability

    - Heap spraying on multi-core systems with the heap quarantine

    - More precise performance evaluation

    - Possible ways to improve the security properties and performance results
    (KASAN quarantine has some interesting settings)

    Best regards,
    Alexander

    > Alexander Popov (2):
    > mm: Extract SLAB_QUARANTINE from KASAN
    > lkdtm: Add heap spraying test
    >
    > drivers/misc/lkdtm/core.c | 1 +
    > drivers/misc/lkdtm/heap.c | 40 ++++++++++++++
    > drivers/misc/lkdtm/lkdtm.h | 1 +
    > include/linux/kasan.h | 107 ++++++++++++++++++++-----------------
    > include/linux/slab_def.h | 2 +-
    > include/linux/slub_def.h | 2 +-
    > init/Kconfig | 11 ++++
    > mm/Makefile | 3 +-
    > mm/kasan/Makefile | 2 +
    > mm/kasan/kasan.h | 75 +++++++++++++-------------
    > mm/kasan/quarantine.c | 2 +
    > mm/kasan/slab_quarantine.c | 99 ++++++++++++++++++++++++++++++++++
    > mm/slub.c | 2 +-
    > 13 files changed, 258 insertions(+), 89 deletions(-)
    > create mode 100644 mm/kasan/slab_quarantine.c
    >

    \
     
     \ /
      Last update: 2020-08-14 23:01    [W:4.999 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site