| Message ID | 20200813151922.1093791-1-alex.popov@linux.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Break heap spraying needed for exploiting use-after-free | expand |
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 >
On Thu, Aug 13, 2020 at 06:19:20PM +0300, Alexander Popov wrote: > 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. Ah yeah, good idea. :) > [...] > 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 1/32 of memory doesn't seem too bad for someone interested in this defense. > 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 That's rather painful, but hackbench can produce some big deltas given it can be an unrealistic workload for most systems. I'd be curious to see the "building a kernel" timings, which tends to be much more realistic for "busy system" without hammering one particular subsystem (though it's a bit VFS heavy, obviously). More notes in the patches...
On 15.08.2020 19:39, Kees Cook wrote: > On Thu, Aug 13, 2020 at 06:19:20PM +0300, Alexander Popov wrote: >> 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. > > Ah yeah, good idea. :) > >> [...] >> 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 > > 1/32 of memory doesn't seem too bad for someone interested in this defense. This can be configured. Quote from linux/mm/kasan/quarantine.c: /* * The fraction of physical memory the quarantine is allowed to occupy. * Quarantine doesn't support memory shrinker with SLAB allocator, so we keep * the ratio low to avoid OOM. */ #define QUARANTINE_FRACTION 32 >> 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 > > That's rather painful, but hackbench can produce some big deltas given > it can be an unrealistic workload for most systems. I'd be curious to > see the "building a kernel" timings, which tends to be much more > realistic for "busy system" without hammering one particular subsystem > (though it's a bit VFS heavy, obviously). I have new results. CPU: Intel Core i7-6500U CPU @ 2.50GHz Test: time make O=../build_out/defconfig/ -j2 CONFIG_SLAB_QUARANTINE disabled: Times: 10m52.978s 10m50.161s 10m45.601s Mean: 649.58s Standard deviation: 3.04 CONFIG_SLAB_QUARANTINE enabled: Times: 10m56.256s 10m51.919s 10m47.903s Mean: 652.026s (+0,38%) Standard deviation: 3.41 This test shows much lower performance penalty. More ideas of tests? Best regards, Alexander
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! 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