Re: [kernel-hardening][RFC PATCH v2 00/12] Add PAX_REFCOUNT overflow protection

[Yves-Alexis Perez <corsac@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

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@chromium.org> wrote:
> > On Thu, Dec 17, 2015 at 6:57 AM, David Windsor <dave@progbits.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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]