ICYMI RAP bypass for root -> kernel exploits on grsec. I did find the angry grsec/PaX replies entertaining too. Remember when grsec had to pay out a quarter mil because he couldn't handle critique? H/T @silviocesare nitter.vloup.ch/uid1000/status/1… theregister.co.uk/2018/06/11…
"Control-Flow Integrity for the Linux kernel: A Security Evaluation" is the work I've done for my Masters thesis where I analyze how the PaX Team's (public) RAP holds up to stop ROP when applied to the Linux kernel. You may want to check out chapter 3. alunos.dcc.fc.up.pt/~up20140…
1
6
This Post was deleted by the Post author.
This Post was deleted by the Post author.
This Post was deleted by the Post author.
no defeats were demonstrated. willfully running a documented insecure config is malice at best, not a defeat. and that still had nothing to do with neither PaX nor RAP per se.
1
Not an insecure config at all, isn't core_pattern __read_only? :) If you say it doesn't have to do with PaX, then it has to do with PaX/grsec.
1
core_pattern isn't read-only under PaX, nor does RAP have anything to do with data-only attacks. on the other hand you yourself admit that following the very explicit advice on grsec_lock prevents your 'attack'.

Dec 3, 2019 · 10:41 PM UTC

2
Isn't KERNEXEC was a PaX feature? ;) You know all too well that RAP is useless if code-injection is possible (it completely eliminates its purpose). Guess what? I also clearly mention this if you've missed it (which turned out to be true of course):
2
what does KERNEXEC have to do with core_pattern not being protected in PaX? and __read_only has nothing to do with KERNEXEC's purpose as it applies to data, not code (be that static or runtime generated), it's only a very small step towards defending against data-only attacks.
1
its the reliance on KERNEXEC is because that's what deals with page protections, so it's a prerequisitive. much like how other defenses in PaX build on others.