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
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
Replying to @uid1000 @scriptjunkie1 @revskills @silviocesare @grsecurity
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.

Dec 4, 2019 · 8:26 AM UTC

1
Replying to @paxteam @scriptjunkie1 @revskills @silviocesare @grsecurity
nitter.vloup.ch/uid1000/status/1… says otherwise? It has to do with KERNEXEC, what makes it possible to write to such data? ;)
Federico Bento @uid1000
13 Sep 2019
Replying to @grsecurity
Where was that? Pretty sure not on this version... Btw, how's that holding up with .rodata as executable? :P
1
pretty sure i said PaX and not grsec? and it's the cpu that does, will you blame it too now? ;)
1
more replies