[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4bc8bb86-613b-1217-6804-cb21a3356bff@linux.com>
Date: Sat, 15 Aug 2020 00:01:03 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>,
Will Deacon <will@...nel.org>, Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>, Steven Rostedt
<rostedt@...dmis.org>, Peter Zijlstra <peterz@...radead.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Patrick Bellasi <patrick.bellasi@....com>,
David Howells <dhowells@...hat.com>, Eric Biederman <ebiederm@...ssion.com>,
Johannes Weiner <hannes@...xchg.org>, Laura Abbott <labbott@...hat.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, kasan-dev@...glegroups.com,
linux-mm@...ck.org, kernel-hardening@...ts.openwall.com,
linux-kernel@...r.kernel.org, Andrey Konovalov <andreyknvl@...gle.com>,
Alexander Popov <alex.popov@...ux.com>
Cc: notify@...nel.org
Subject: Re: [PATCH RFC 0/2] Break heap spraying needed for exploiting
use-after-free
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
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
