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…

Open Source Security hit with bill for defamation claim

Judge okays $260K in defense costs to Bruce Perens and lawyers under anti-SLAPP

theregister.com
Federico Bento @uid1000
13 Sep 2019
"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'.
2
Replying to @paxteam @uid1000 @scriptjunkie1 @revskills @silviocesare @grsecurity
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.

Dec 4, 2019 · 8:27 AM UTC