[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 May 2017 23:27:03 +0200
From: Mathias Krause <minipli@...glemail.com>
To: David Gens <david.gens@...tu-darmstadt.de>
Cc: Kees Cook <keescook@...omium.org>, Daniel Cegiełka <daniel.cegielka@...il.com>,
kernel-hardening@...ts.openwall.com
Subject: Re: It looks like there will be no more public
versions of PaX and Grsec.
On 2 May 2017 at 13:11, David Gens <david.gens@...tu-darmstadt.de> wrote:
> So tell me how exactly a PaX-hardened kernel with a memory-corruption bug
> prevents an adversary from modifying critical data, such as the page tables
> in a data-only attack?
It doesn't as it has not mitigation for data-only attacks yet. But
neither does a vanilla kernel. It's even worse on vanilla Linux where
the page tables simply can be written to with a write-what-where
primitive. PaX can, however, protect the page tables from getting
modified by having them write-protected. So yes, that makes it more
secure.
> IMHO the "PaX mitigates Memory-corruption" argument
> is wishful thinking, and now that PaX is gone users cannot fool themselves
> any longer into thinking "My System is Secure". That awareness is actually
> good no?
What about KERNEXEC and CONSTIFY taking care of protecting a lot of
data structures? What about SIZE_OVERFLOW successfully preventing know
overflow bugs, like the various keys related ones? What about RAP,
ensuring control flow integrity? That's nothing, you say? Ridiculous.
Thanks,
Mathias
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.
