On Wed, May 10, 2023 at 7:44 PM Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx> wrote: > > On Mon, May 8, 2023 at 12:53 AM GONG, Ruiqi <gongruiqi1@xxxxxxxxxx> wrote: > > > > When exploiting memory vulnerabilities, "heap spraying" is a common > > technique targeting those related to dynamic memory allocation (i.e. the > > "heap"), and it plays an important role in a successful exploitation. > > Basically, it is to overwrite the memory area of vulnerable object by > > triggering allocation in other subsystems or modules and therefore > > getting a reference to the targeted memory location. It's usable on > > various types of vulnerablity including use after free (UAF), heap out- > > of-bound write and etc. > > > > There are (at least) two reasons why the heap can be sprayed: 1) generic > > slab caches are shared among different subsystems and modules, and > > 2) dedicated slab caches could be merged with the generic ones. > > Currently these two factors cannot be prevented at a low cost: the first > > one is a widely used memory allocation mechanism, and shutting down slab > > merging completely via `slub_nomerge` would be overkill. > > > > To efficiently prevent heap spraying, we propose the following approach: > > to create multiple copies of generic slab caches that will never be > > merged, and random one of them will be used at allocation. The random > > selection is based on the address of code that calls `kmalloc()`, which > > means it is static at runtime (rather than dynamically determined at > > each time of allocation, which could be bypassed by repeatedly spraying > > in brute force). In this way, the vulnerable object and memory allocated > > in other subsystems and modules will (most probably) be on different > > slab caches, which prevents the object from being sprayed. > > > > The overhead of performance has been tested on a 40-core x86 server by > > comparing the results of `perf bench all` between the kernels with and > > without this patch based on the latest linux-next kernel, which shows > > minor difference. A subset of benchmarks are listed below: > > > > Please Cc maintainers/reviewers of corresponding subsystem in MAINTAINERS file. > > I dont think adding a hardening feature by sacrificing one digit > percent performance > (and additional complexity) is worth. Heap spraying can only occur > when the kernel contains > security vulnerabilities, and if there is no known ways of performing > such an attack, > then we would simply be paying a consistent cost. > And does the kernel not contain security vulnerabilities? :v This feature is opt-in and locked behind a CONFIG_ and the kernel most certainly has security vulnerabilities. So... I don't see why adding the hardening feature would be a bad idea, barring it being a poor hardening feature, the patch being poor or the complexity being overwhelming. -- Pedro
