Date: Tue, 18 Aug 2020 17:45:50 +0200 From: Andrey Konovalov <andreyknvl@...gle.com> To: Alexander Popov <alex.popov@...ux.com>, Dmitry Vyukov <dvyukov@...gle.com>, Alexander Potapenko <glider@...gle.com>, Andrey Ryabinin <aryabinin@...tuozzo.com>, kasan-dev <kasan-dev@...glegroups.com> Cc: Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>, Will Deacon <will@...nel.org>, 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>, Linux Memory Management List <linux-mm@...ck.org>, kernel-hardening@...ts.openwall.com, LKML <linux-kernel@...r.kernel.org>, notify@...nel.org Subject: Re: [PATCH RFC 1/2] mm: Extract SLAB_QUARANTINE from KASAN On Mon, Aug 17, 2020 at 7:32 PM Alexander Popov <alex.popov@...ux.com> wrote: > > On 15.08.2020 19:52, Kees Cook wrote: > > On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote: > >> Heap spraying is an exploitation technique that 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. Allocating a kernel object with the same size and > >> controlled contents allows overwriting the vulnerable freed object. > >> > >> Let's extract slab freelist quarantine from KASAN functionality and > >> call it CONFIG_SLAB_QUARANTINE. This feature breaks widespread heap > >> spraying technique used for exploiting use-after-free vulnerabilities > >> in the kernel code. > >> > >> 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. > > > > It may be worth clarifying that this is specifically only direct UAF and > > doesn't help with spray-and-overflow-into-a-neighboring-object attacks > > (i.e. both tend to use sprays, but the former doesn't depend on a write > > overflow). > > Andrey Konovalov wrote: > > If quarantine is to be used without the rest of KASAN, I'd prefer for > > it to be separated from KASAN completely: move to e.g. mm/quarantine.c > > and don't mention KASAN in function/config names. > > Hmm, making quarantine completely separate from KASAN would bring troubles. > > Currently, in many special places the allocator calls KASAN handlers: > kasan_cache_create() > kasan_slab_free() > kasan_kmalloc_large() > kasan_krealloc() > kasan_slab_alloc() > kasan_kmalloc() > kasan_cache_shrink() > kasan_cache_shutdown() > and some others. > These functions do a lot of interesting things and also work with the quarantine > using these helpers: > quarantine_put() > quarantine_reduce() > quarantine_remove_cache() > > Making quarantine completely separate from KASAN would require to move some > internal logic of these KASAN handlers to allocator code. It doesn't look like there's quite a lot of KASAN-specific logic there. All those quarantine_*() calls are either at the beginning or at the end of some kasan annotations, so it should be quite easy to move those out. E.g. quarantine_reduce() can be moved together with the gfpflags_allow_blocking(flags) check and put before kasan_kmalloc() calls (or maybe also into some other places?), quarantine_put() can be put after kasan_slab_free(), etc. > In this patch I used another approach, that doesn't require changing the API > between allocators and KASAN. I added linux/mm/kasan/slab_quarantine.c with slim > KASAN handlers that implement the minimal functionality needed for quarantine. > > Do you think that it's a bad solution? This solution doesn't look clean. Here you provide a second KASAN runtime implementation, parallel to the original one, which only does quarantine. It seems much cleaner to put quarantine logic into a separate module, which can be either used independently, or together with KASAN built on top of it. Maybe other KASAN contributors have an opinion on this?
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.