From: Alexander Popov <alex.popov@linux.com>
To: Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
Will Deacon <will@kernel.org>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Patrick Bellasi <patrick.bellasi@arm.com>,
David Howells <dhowells@redhat.com>,
Eric Biederman <ebiederm@xmission.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Laura Abbott <labbott@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org,
Andrey Konovalov <andreyknvl@google.com>,
Alexander Popov <alex.popov@linux.com>
Cc: notify@kernel.org
Subject: Re: [PATCH RFC 0/2] Break heap spraying needed for exploiting use-after-free
Date: Sat, 15 Aug 2020 00:01:03 +0300 [thread overview]
Message-ID: <4bc8bb86-613b-1217-6804-cb21a3356bff@linux.com> (raw)
In-Reply-To: <20200813151922.1093791-1-alex.popov@linux.com>
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
>
next prev parent reply other threads:[~2020-08-14 21:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 15:19 [PATCH RFC 0/2] Break heap spraying needed for exploiting use-after-free Alexander Popov
2020-08-13 15:19 ` [PATCH RFC 1/2] mm: Extract SLAB_QUARANTINE from KASAN Alexander Popov
2020-08-15 16:52 ` Kees Cook
2020-08-17 11:53 ` Andrey Konovalov
2020-08-17 17:32 ` Alexander Popov
2020-08-18 15:45 ` Andrey Konovalov
2020-08-18 20:50 ` Alexander Popov
2020-08-15 18:54 ` Matthew Wilcox
2020-08-16 19:59 ` Pavel Machek
2020-08-17 21:03 ` Alexander Popov
2020-08-17 20:34 ` Alexander Popov
2020-08-13 15:19 ` [PATCH RFC 2/2] lkdtm: Add heap spraying test Alexander Popov
2020-08-15 16:59 ` Kees Cook
2020-08-17 17:54 ` Alexander Popov
2020-08-17 18:24 ` Eric W. Biederman
2020-08-17 19:24 ` Kees Cook
2020-08-14 21:01 ` Alexander Popov [this message]
2020-08-15 16:39 ` [PATCH RFC 0/2] Break heap spraying needed for exploiting use-after-free Kees Cook
2020-08-18 9:08 ` Alexander Popov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4bc8bb86-613b-1217-6804-cb21a3356bff@linux.com \
--to=alex.popov@linux.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=cl@linux.com \
--cc=dhowells@redhat.com \
--cc=dvyukov@google.com \
--cc=ebiederm@xmission.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=krzk@kernel.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=masahiroy@kernel.org \
--cc=mhiramat@kernel.org \
--cc=notify@kernel.org \
--cc=patrick.bellasi@arm.com \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).