[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jan 2016 21:57:17 +0100
From: Yves-Alexis Perez <corsac@...ian.org>
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 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,
--
Yves-Alexis
Download attachment "signature.asc" of type "application/pgp-signature" (474 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.
