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'.
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
based on your incompetence and outright childish behaviour you're not on the list of people i'd ever trust or even ask to evaluate anything remotely related to security.
Dec 4, 2019 · 8:29 AM UTC
1