linux-kernel - Re: [PATCH RFC] Randomized slab caches for kmalloc()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0f3abe0f-216b-dda6-38c4-26ffa79d966f@huawei.com>
Date:   Tue, 25 Apr 2023 11:55:18 +0800
From:   Gong Ruiqi <gongruiqi1@...wei.com>
To:     Alexander Lobakin <aleksander.lobakin@...el.com>
CC:     Hyeonggon Yoo <42.hyeyoo@...il.com>,
        Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...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>,
        Vlastimil Babka <vbabka@...e.cz>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Alexander Potapenko <glider@...gle.com>,
        Marco Elver <elver@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>, <kasan-dev@...glegroups.com>,
        Kees Cook <keescook@...omium.org>,
        <linux-hardening@...r.kernel.org>,
        Paul Moore <paul@...l-moore.com>,
        <linux-security-module@...r.kernel.org>,
        James Morris <jmorris@...ei.org>,
        Wang Weiyang <wangweiyang2@...wei.com>,
        Xiu Jianfeng <xiujianfeng@...wei.com>
Subject: Re: [PATCH RFC] Randomized slab caches for kmalloc()



On 2023/04/24 21:46, Alexander Lobakin wrote:
> From: Gong, Ruiqi <gongruiqi1@...wei.com>
> Date: Mon, 24 Apr 2023 10:54:33 +0800
> 
> ...
> 
>>
>>> It's fast enough according to Jason... `_RET_IP_ % nr` doesn't sound
>>> "secure" to me. It really is a compile-time constant, which can be
>>> calculated (or not?) manually. Even if it wasn't, `% nr` doesn't sound
>>> good, there should be at least hash_32().
>>
>> Yes, `_RET_IP_ % nr` is a bit naive. Currently the patch is more like a
>> PoC so I wrote this. Indeed a proper hash function should be used here.
>>
>> And yes _RET_IP_ could somehow be manually determined especially for
>> kernels without KASLR, and I think adding a per-boot random seed into
>> the selection could solve this.
> 
> I recall how it is done for kCFI/FineIBT in the x86 code -- it also uses
> per-boot random seed (although it gets patched into the code itself each
> time, when applying alternatives). So probably should be optimal enough.
> The only thing I'm wondering is where to store this per-boot seed :D
> It's generic code, so you can't patch it directly. OTOH storing it in
> .data/.bss can make it vulnerable to attacks... Can't it?

I think marking the seed with __ro_after_init is enough, since we don't
mind it could be read by the attacker.

Given that the code paths the attacker can utilize to spray the heap is
limited, our address-related randomness in most cases prevents
kmalloc()s on these paths from picking the same cache the vulnerable
subsystem/module would pick. Although _RET_IP_ of kmalloc()s could be
known, without tampering the source code and rebuilding the image, the
attacker can't do anything to make those caches collide if the cache
selection algorithm says they don't.

So in my perspective the per-boot random seed is more like an
enhancement: if one day, by analyzing the open source code, the attacker
does find a usable kmalloc that happens to pick the same cache with the
vulnerable subsystem/module, the seed could make his/her effort wasted ;)

> 
>>
>> I will implement these in v2. Thanks!
>>
>>>
>>> Thanks,
>>> Olek
>>>
> 
> Thanks,
> Olek