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
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
that's pretty rich from someone whose openning salvo was about 'entertaining himself with angry replies'. maybe try something with more substance, like technical info next time?
1
as for the point of his research, why not let him tell you exactly (from his 2nd mail to me over a year ago): "My goal is to exploit the kernel[...]". you tell me how to pull that off without a single bug...
1
quotes are a literary device used for diverse purposes, so instead of assuming any, maybe you could have asked what i meant? and still not a technical argument, i note.
a myth from the same academic jokers^Wresearchers who graced us with their ASLR 'research' in the past: in res.mdpi.com/d_attachment/ap… table 2 shows RAP vulnerable to ret2user (it isn't, after all we invented KERNEXEC/i386 in 2003 and UDEREF in 2006 :) but everybody else not...
2
14
23
In fairness, the authors cite another paper for the RAP statement. The cited paper argues that RAP is vulnerable to ret2user attacks, because it doesn't protect register contents on the kernel's interrupt stack. Is that not the case? (I don't know how RAP works personally.)
1
PaX Team retweeted
I always like bugs that prove you're the first to ever use something. We seem to be the first ones to try to use the event registration system for GCC plugins since it was introduced almost a decade ago: gcc.gnu.org/bugzilla/show_bu…
1
4
32
"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…
6
66
5
204
So now you say it's a KERNEXEC problem but then somehow the issue isn't in PaX? Isn't KERNEXEC a PaX feature? Guess who's being contradicting ;)
1
what makes you think that KERNEXEC in PaX = KERNEXEC in grsec? did you demonstrate the problem in PaX? i know for a fact that you never did (and never will) since it doesn't exist there. you were wrong again, simple as that.
1
Why do you feel so entitled to have known my research before publication? Did you want to write it for me? I asked you if you wanted to take a look at it in case it would put your users at risk, but you didn't really care.
1
*you* promised to share your results with us, didn't you? and now that i hold you up to that promise, you're evading the question. i guess it'd be a bit too embarrasing to admit your dishonesty.
1
you presented a gdb based 'exploit' as one equivalent to exploiting an 'arbitrary read-write bug'.
1
I've already told you which feature it is, but you seem more interested in twisting the things I say so that you can actually come up with something to blab about
1
you have not otherwise i wouldn't be asking. you put a KERNEXEC problem in a RAP chapter and you're still unable to decide which it is. not to mention the totally wrong characterization of this issue being in PaX itself.
1
when did you change your mind and based on what? when did you tell us about your change of mind (never)? why did you then ask us about your thesis *just before* going public with it? questions, eternal questions...
1
Yes. Why wouldn't I think that? "The unreadable kernel stack feature prevents cross-task information leaks and corruption"
1
So you're telling me with debugger access one can't read from and write to anywhere in memory an arbitrary number of times?
1
I did come in good faith. I even commented with a few people how surprising it was you (in the very early stages) being nice and all. Then you start being your normal self, questions unanswered, I just thought you stopped caring.
1
in hindsight, you only pretended and i'm glad i didn't spend my very little free time on your questions that a net search would have answered. so evade your promise with more ad hominem, that won't change the fact that you never delivered but feel so entitled to demand help.
1
Not really contradicting (you may want to look up the definition for that word before you throw it around). It has to do with PaX just as much as it has to do with grsec, since it was code added by *both* parties that lead to the described problem
1
resort to ad homine when you're out of arguments? looks like your typical self ;). it's a contradiction when you can't decide which feature you found an issue with. and you have yet to prove that it exists in PaX as well. not holding my breath...
1
I asked you some questions in november, but I started working on the thesis in late february. So there's that time gap right there that might've ticked you off.
1
why are you evading the question? did you promise to share your findings with us or not? did you do so or not?
1
Maybe, just maybe, irq stacks were left readable. All of this would've been easier to determine if I was testing on the 'real thing', which you didn't let me.
1