Believing in numbers and fair evaluation, I've compared RAP and LLVM-CFI. RAP is faster, LLVM-CFI is more precise. RAP is incredibly hard to use and its future is uncertain while LLVM-CFI is just a command line argument away. Details at nebelwelt.net/blog/20181226-… Comments welcome 🤗
18
28
79
- you were asked for your benchmark sources used in the CSUR17 'survey' yet didn't provide anything. [3/n]
- you were told that the public kernel version is not a representative of what RAP can do, especially for userland. what gives? [2/n]
your 'evaluation' suffers from serious problems, i just hope this was due to your apparent hurry to save face (you have yet to answer nitter.vloup.ch/paxteam/status/1…) and does not represent the quality of your academic research work. let's dive in, shall we ;) [1/n]
nitter.vloup.ch/paxteam/status/1… (FPValidator reference), nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1… (which also contradicts your late statements of RAP not being available btw), nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1… are a good start.
1
1
To learn more about @grsecurity #RAP, checkout our repo for its gcc plugin as well as a sample code:
github.com/sajjadium/typed-c…
2
8
I got your point and I removed it from our repo. Sorry for the violation. It was an honest mistake. We are wondering if you give us the permission to distribute the binary since we believe it will be very useful to academic researchers? Thx in advance.
2
the problem isn't with distribution per se (that plugin's license is GPLv2 which specifically allows distribution) but that said distribution is conditional on your fulfilling your obligations of section 3. e.g., providing the src/make instructions would satisfy it.
1
After we conjugated through all possible permutations of "apply ML wrongly to a security problem which is, in fact, adversarial", I really do not like how some people seem to like going through "conjugate through all possible permutations of how these can be broken"....
3
4
36
Have an approach that efficiently controls all aliases. I’d be interested to hear what you think. Basic idea is map all PTs as read only and create small interface while mediating access to CR0, CR3, CR4, and EFER. Overhead less than 3% for kcompile. nestedkernel.org
3
1
This plugin is compiled from the earlier open source version (kernel patch) that was available on your website. We do not publish any source code and this plugin is just for academic purposes.
1
1
did you read the GPLv2 section i pointed out? it's about distributing a binary (which you did) *without* meeting your obligations as detailed in that section.
1
1
Does RAP protect access to the MMU? Specifically CR0. If not then I’m sorry you lose. But yeah I love RAP. Way better than the policy enforced by KCoFI, which is obviously terribly imprecise for returns. And yes I totally missed citations on NK paper, sorry.
3
needless to say, i've got plans for addressing that (KERNSEAL from 2005 and some more from later years) but priorities have been elsewhere so i've got nothing to present you for now.
1
RAP's job isn't to ensure immutability of code/etc, we have other features for that (KERNEXEC/etc) and no, they're far from complete in that regard, a powerful enough data-only attack can trivially overwrite PTEs to create writable aliases. fixing that w/o perf impact is hard ;).
2
That's unfortunately not going to work, we only evaluate open source implementations. But I invite you to provide the target set evaluation and do a write-up where you compare your precision against llvm-cfi
2
nitter.vloup.ch/paxteam/status/1… (FPValidator reference), nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1… (which also contradicts your late statements of RAP not being available btw), nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1… are a good start.
no novelty there? then tell me which of the evaluated works comes anywhere near its performance&security level? oh wait, you'd actually have had to evaluate it to draw that conclusion. next excuse? ;)
1
Oh, we have not agreed on an attacker model yet. For SafeStack, we assume that the attacker already has arbitrary read/write and the goal is to protect control flow. Under SafeStack (or ShadowStack) you cannot illegally hijack CF to alternate locations but with RAP you can
2
safestack is breakable by design since it doesn't withstand an arbitrary read, IIRC there was a paper that implemented such an attack in practice. the only saving grace would be restricting the 'arbitrary' part but then its performance tanks and becomes worse than RAP and others.
SafeStack is pretty much trivially breakable with arbitrary read. RAP cookies are breakable too with arbitrary read, but then it’s backed up with the type equivalence. Also, specialized kernel stuff makes RAP cookies much better, I don’t know if you evaluated kernel stuff.
2
RAP cookies (their primary use case is the kernel, not userland) are not that trivial to break because they change per syscall and kstacks are isolated from other processes so in practice you need very special bugs to be able to read it *and* make use of it in a payload.
1
"but isn’t it your job to evaluate all the important, practical implementations available?" No. If we publish new work we compare against available implementations of the state of the art. RAP is neither the state of the art nor available.
3
so what you downloaded the other day wasn't RAP, i see. and how do you know it's not state of the art if you never evaluated it? but then last week you said that you had so maybe clear up that confusion first?
1
i don't distribute that (it's a commercial product for a reason), what i can do is run your tests and give you the information you need from the results.
1
My main point is that RAP cannot be reproduced or used in practice. So instead of arguing over Twitter for several days invest that time into a writeup and clean release and we'd all be happy? 👍
1
why do you keep spreading this disinformation? you patch in PaX, enable RAP in menuconfig and off you go. thousands of people managed to use it since 2016, one would hope with a PhD you can too. if you want something outside the kernel then you'll have to work with me.
1
We apparently see things differently. You started these discussions. I'm happy to talk via Skype/Hangouts/whatever or meet in person 🤗
1
why can't you answer my questions here in public? i hope you realize that refusing to answer them seriously questions your honesty and integrity (both at the personal and academic levels).
1
Also, I don't think our viewpoints are unmergable. These twitter discussions just end up being toxic.
2
what i find toxic is your personal attacks, lack of apologies when you're proven wrong and lack of responses to the apparently 'tough' questions i asked you (noexec.txt/FPValidator/your earlier RAP evaluation, etc in case you 'forgot').
2