[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1453338072.4942.16.camel@gmail.com>
Date: Wed, 20 Jan 2016 20:01:12 -0500
From: Daniel Micay <danielmicay@...il.com>
To: kernel-hardening@...ts.openwall.com, Kees Cook <keescook@...omium.org>
Cc: David Windsor <dave@...gbits.org>
Subject: Re: [RFC PATCH v2 00/12] Add PAX_REFCOUNT
overflow protection
On Wed, 2016-01-20 at 21:57 +0100, Yves-Alexis Perez wrote:
> On mar., 2016-01-19 at 11:07 -0800, Kees Cook wrote:
> > Hi David,
> >
> > On Thu, Dec 17, 2015 at 12:55 PM, Kees Cook <keescook@...omium.org>
> > wrote:
> > > On Thu, Dec 17, 2015 at 6:57 AM, David Windsor <dave@...gbits.org>
> > > wrote:
> > > > NOTE: This is a v2 submission because patch 3/5 in v1 was too
> > > > large to
> > > > sent
> > > > to kernel-hardening. Taking that as a sign that the patch
> > > > needed to be
> > > > split,
> > > > I'm sending this version of the patchset, with the patches split
> > > > more or
> > > > less
> > > > on a per-maintainer basis (except for those in drivers/).
> >
> > How's the next spin coming? It looks like we have some new real-
> > world
> > examples of exploits that would have been blocked by this
> > protection:
> >
> > http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a
> > -linux-k
> > ernel-vulnerability-cve-2016-0728/
> >
> >
> One thing which is surprising (I have to admit I'm not really an
> expert on how
> SLAB works) is how easy it apparently is to have multiple allocations
> end up
> at the same place. You don't even have to *know* the exact address.
>
> Wouldn't it be possible to at least have some randomization here, so
> new
> object are not at the same place as the not-freed-ones, somehow
> preventing the
> use-after-free and forcing an attacker to do some heap massaging?
>
> Regards,
It could do some fine-grained randomization. It does have a measurable
performance cost since it makes allocations colder and there isn't much
room for adding entropy but it does add up over time. Depending on the
locking design it could also hurt there too.
Take a look at OpenBSD malloc if you're interested in it. It has a few
forms of randomization and they do add up:
* small array of quarantined pointers, free(ptr) randomly swaps with one
and frees that (wastes some memory, makes allocations colder) - can also
have a feature checking that junk filled for sanitization is still in
place when moving out of the quarantine at a further performance cost
(which I recently upstreamed for OpenBSD malloc)
* picking a random slot within a slab (makes allocations colder and
slows down the allocator a bit)
* picking a random slab list to satisfy each allocation (significantly
increases worst-case memory usage by spreading stuff out)
* page cache randomization (i.e. randomization of the layer below slabs
which in userspace means the allocator cache and fine-grained mmap rnd,
but it still applies to the kernel's allocation of the slab pages)
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
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.
