and what do you do with those discovered related works? bury them and never ever mention them in your own work or give proper credit? as a sidenote, the CCS05 CFI paper references my other work (ASLR), *except* the one that made their work not novel.
2
2
9
Cite it. Kind of stupid or passive aggressive question ;)
1
3
thanks for playing, it was neither :). you just shamed pretty much the entire academic CFI crowed.
1
I disagree on that part. You assume things you cannot know, that is someone being aware of a specific work maliciously avoids citing it for whatever reasons. And additionally, as this went through peer review, that the reviewers were fine with this. [1/2]
2
i don't assume, i know for a fact that say @gannimo knew about RAP when he wrote some of his CFI related papers. now what? ;)
1
You mean our CFI survey from '17 where we cited your work? What are you trying to imply?
1
1
that and CFIXX, HEXTYPE, etc, where's the citation of my work in there? that CSUR paper added a few down-playing words about my early work and zero about RAP itself, never mind an actual evaluation. you could have asked me to help conduct the tests but you never did. why not?
2
1
2
CFIXX targets vtable pointer integrity for C++. HexType is a sanitizer for C++ type safety. Why should we cite your work there? You describe protecting returns through a set check and read-only code function pointers. We cited some CFI work but not everything.
2
1
for the same reason you cited the Abadi paper? pax-future.txt has all the basic ideas that i later implemented in RAP and predated the CFI paper by 2+ years..
3
Let me reiterate: in the pax-future paper you propose protecting returns. For the forward edge you only propose to write-protect as many function pointers as possible. While reducing attack surface, that's not CFI 🙃 (Also, idea != design, implementation, evaluation, discussion)
6
4
nope, read nitter.vloup.ch/paxteam/status/1… again and understand what exemplify means. for background, all these docs were written during a short contracting gig in 2002 for subject matter experts at the client who were already familiar with my work, academic publication wasn't the focus.
(i think pax.grsecurity.net/docs/ is a better reference). there're 3 strategies outlined for control flow protection in there (read-only/type check/'encryption'), each exemplified with one kind of code ptr but that doesn't mean they don't apply to the other kind.

Dec 20, 2018 · 11:50 PM UTC

1