From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 033FBC4727E for ; Tue, 6 Oct 2020 18:38:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 46EA720789 for ; Tue, 6 Oct 2020 18:38:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PM0JMNHP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46EA720789 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2E4486B005C; Tue, 6 Oct 2020 14:38:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 26D5C6B005D; Tue, 6 Oct 2020 14:38:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10D2E900002; Tue, 6 Oct 2020 14:38:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id CF9BD6B005C for ; Tue, 6 Oct 2020 14:38:04 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6082F180AD804 for ; Tue, 6 Oct 2020 18:38:04 +0000 (UTC) X-FDA: 77342360088.05.mouth22_1809e57271c8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 4394A18014C8E for ; Tue, 6 Oct 2020 18:38:04 +0000 (UTC) X-HE-Tag: mouth22_1809e57271c8 X-Filterd-Recvd-Size: 8434 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 18:38:03 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id qp15so19112801ejb.3 for ; Tue, 06 Oct 2020 11:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iiFZhuwHNBTR9+4Q7mOK5ZAfJhgSvj1um5FsudlQqFU=; b=PM0JMNHPiD6wmU2ArxvuwJ2NKPRtEQlVKHA276QyadNFqaMC+5g4jmPjNKlBwa83lk KMrg1mI1j/QkHGefhK1gI+ESdACDTe3iR9kYZQrCPSGlv2WcAAciQultmozXlq9o8P7n OzFWfxJPVfi73YPtx4jDIKUZYiqLExKGK45yBtr9Ed9U6rDQzCyxD37PVNCGIQ9p4mxt 0VJfoDcon+b/gOPiEX06CZJpoZrT2164DEu2j2GLCEfF3t4IFdB9MPh3QP7o12hUq68R K1syuLf2mpvfTcraEsjAGe15fUQn+pdBuvT0W5IG9/qT2hQPTKLCLCFy//thqB8KRanz J6cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iiFZhuwHNBTR9+4Q7mOK5ZAfJhgSvj1um5FsudlQqFU=; b=ZKICj6OnosPOTVtYs6rUhqo/V+8/ohbur1CBI/WKvCbM57yARl/HOqs+LdPtBhFByv gzdrHQYUy8BYl0jl4JHA/QqnftD1p3FOBUSTxDmQpF2V667EoZFmFKappjoku6C8SMQO sHs6fEytp8NyivfHN8YDrwhamoukgUAfzDSMTqNc8pSfiC3IdAgYmUPJrEJUbxfxrR5k fisVEUuooo0rwG5DbM4xSt7UWgKKh207pbGA2qDqaXXM2ZxT/HeVFsCMzlMYZbCr6eoV v5P5eZG79uSUyUEkGnKToL4NHO1wJNEzT9L+0EOKlgl1YZv5wJYKZdrcPzqS4k5J10+P w2tg== X-Gm-Message-State: AOAM532lKwCowLMzm3/eR/pRx2SeAd7VNb7b6e8PXSCRJ0HPk/MRN0Vr SJ1AkJgK+OYa7IDwTMVBEMeYplOVMjoV0zzBROSVRw== X-Google-Smtp-Source: ABdhPJwIor6UpBlGj2PuTDA18/0MI0H/2wNMCyrRIxHFGEdipoCiKU3u0FaVJ0EJpvaRPXT5N/b5LLBabc5Ly2lWG94= X-Received: by 2002:a17:906:9156:: with SMTP id y22mr981885ejw.184.1602009482216; Tue, 06 Oct 2020 11:38:02 -0700 (PDT) MIME-Version: 1.0 References: <20200929183513.380760-1-alex.popov@linux.com> <91d564a6-9000-b4c5-15fd-8774b06f5ab0@linux.com> <1b5cf312-f7bb-87ce-6658-5ca741c2e790@linux.com> In-Reply-To: <1b5cf312-f7bb-87ce-6658-5ca741c2e790@linux.com> From: Jann Horn Date: Tue, 6 Oct 2020 20:37:35 +0200 Message-ID: Subject: Re: [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free To: Alexander Popov Cc: Kees Cook , Will Deacon , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Masahiro Yamada , Masami Hiramatsu , Steven Rostedt , Peter Zijlstra , Krzysztof Kozlowski , Patrick Bellasi , David Howells , Eric Biederman , Johannes Weiner , Laura Abbott , Arnd Bergmann , Greg Kroah-Hartman , Daniel Micay , Andrey Konovalov , Matthew Wilcox , Pavel Machek , Valentin Schneider , kasan-dev , Linux-MM , Kernel Hardening , kernel list , notify@kernel.org Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 6, 2020 at 7:56 PM Alexander Popov wrote: > > On 06.10.2020 01:56, Jann Horn wrote: > > On Thu, Oct 1, 2020 at 9:43 PM Alexander Popov wrote: > >> On 29.09.2020 21:35, Alexander Popov wrote: > >>> This is the second version of the heap quarantine prototype for the Linux > >>> kernel. I performed a deeper evaluation of its security properties and > >>> developed new features like quarantine randomization and integration with > >>> init_on_free. That is fun! See below for more details. > >>> > >>> > >>> Rationale > >>> ========= > >>> > >>> Use-after-free vulnerabilities in the Linux kernel are very popular for > >>> exploitation. There are many examples, some of them: > >>> https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html > > Hello Jann, thanks for your reply. > > > I don't think your proposed mitigation would work with much > > reliability against this bug; the attacker has full control over the > > timing of the original use and the following use, so an attacker > > should be able to trigger the kmem_cache_free(), then spam enough new > > VMAs and delete them to flush out the quarantine, and then do heap > > spraying as normal, or something like that. > > The randomized quarantine will release the vulnerable object at an unpredictable > moment (patch 4/6). > > So I think the control over the time of the use-after-free access doesn't help > attackers, if they don't have an "infinite spray" -- unlimited ability to store > controlled data in the kernelspace objects of the needed size without freeing them. > > "Unlimited", because the quarantine size is 1/32 of whole memory. > "Without freeing", because freed objects are erased by init_on_free before going > to randomized heap quarantine (patch 3/6). > > Would you agree? But you have a single quarantine (per CPU) for all objects, right? So for a UAF on slab A, the attacker can just spam allocations and deallocations on slab B to almost deterministically flush everything in slab A back to the SLUB freelists? > > Also, note that here, if the reallocation fails, the kernel still > > wouldn't crash because the dangling object is not accessed further if > > the address range stored in it doesn't match the fault address. So an > > attacker could potentially try multiple times, and if the object > > happens to be on the quarantine the first time, that wouldn't really > > be a showstopper, you'd just try again. > > Freed objects are filled by zero before going to quarantine (patch 3/6). > Would it cause a null pointer dereference on unsuccessful try? Not as far as I can tell. [...] > >> N.B. There was NO performance optimization made for this version of the heap > >> quarantine prototype. The main effort was put into researching its security > >> properties (hope for your feedback). Performance optimization will be done in > >> further steps, if we see that my work is worth doing. > > > > But you are pretty much inherently limited in terms of performance by > > the effect the quarantine has on the data cache, right? > > Yes. > However, the quarantine parameters can be adjusted. > > > It seems to me like, if you want to make UAF exploitation harder at > > the heap allocator layer, you could do somewhat more effective things > > with a probably much smaller performance budget. Things like > > preventing the reallocation of virtual kernel addresses with different > > types, such that an attacker can only replace a UAF object with > > another object of the same type. (That is not an idea I like very much > > either, but I would like it more than this proposal.) (E.g. some > > browsers implement things along those lines, I believe.) > > That's interesting, thank you. Just as some more context of how I think about this: Preventing memory corruption, outside of stuff like core memory management code, isn't really all *that* hard. There are schemes out there for hardware that reliably protects the integrity of data pointers, and such things. And if people can do that in hardware, we can also emulate that, and we'll get the same protection in software. The hard part is making it reasonably fast. And if you are willing to accept the kind of performance impact that comes with gigantic quarantine queues, there might be more effective things to spend that performance on?