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
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.
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
also you didn't answer why aslr.txt isn't held up to this standard of yours (N.B. i'm not in academia) and why you excluded RAP from the CSUR survey.
1
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
In the extract from @gannimo above, it's not like the PaX team isn't credited. The problem is the extent of what's credited. The answer to "lack of communication" isn't "it's all in the code".
2
see nitter.vloup.ch/paxteam/status/1… and the so far total silence on my question...
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
My point is that it's not my job to reverse engineer RAP. If you want citations, then make it citable. Simply having an idea or an implementation is not enough. You need to write it up as well. Communication is part of science. I'm happy to help review your paper if you want 🙂
2
4
why do you and others cite aslr.txt then? clearly you're trying to make an excuse only here. and the implementation is the *most* important part of any work, that's what matters, that's what defines it, what people can use.
1
If I recall correctly (been awhile) there were some important details that were not clear from the available marketing copy or H2HC slides. Some of that was cleared up when I took a look at the sample binaries protected by RAP, some wasn’t. Certainly no good way to cite this.
1
the source code for RAP (linux kernel version) has been public for years, all you needed to do is look at the code yourself. and if you had lingering questions after that, why did you never ask me?
Also, we once tried to compare against RAP in a project but ran into compatibility issues and gave up in the end as it was not worth the effort compared to the (stronger?) LLVM-CFI/shadow stack combination.
1
1
1
2
what compatibility issues and why did you never report anything to me? FWIW, the public version works with linux fine, it's production quality.
2
I invite you to write up what RAP does so that we have a clear description that can be used to compare it to other work. As is, the presentation is too sparse for a clear cut comparison. We could fuzzy cite it but then you'll not be happy either.
3
2
in your very next tweet you admit that you do in fact know what it does and even tried to compare it (given that the kernel version of RAP has been open source for years now). next lame excuse? btw, how can you cite aslr.txt given the above requirements?
1
If you want your work cited, go write it up properly. Academia frowns on citation of commercial tools without at least a whitepaper explaining and evaluating the research.
2
2
i never wrote up ASLR 'properly' either yet that didn't prevent anyone from referencing aslr.txt. how do you explain that? also the kernel version of RAP is open source, what prevents you from seeing yourself how it works?
While your backward edge protection is neat (and similar to the Abadi-CFI backward edge checks), RAD ieeexplore.ieee.org/document… came out in a similar time (IIRC you mentioned pax-future was written in 2003, RAD came out at ICDCS in 2001)
1
2
AFAICT, RAD and any previous work (to mine, that is) had no generalized concept of control flow integrity (never mind a general exploit technique categorization based defense strategy).
In web.archive.org/web/20070614… (oldest reference I could find) your proposed forward-edge protection makes code pointers read-only. This will reduce the attack surface by restricting targets for *some* pointers but leave many code pointers unprotected.
2
1
(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.
1
1
2
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
thanks for playing, it was neither :). you just shamed pretty much the entire academic CFI crowed.
1
Many things are discovered multiple times
It happens so often that me or my colleagues have a brilliant idea and just in the search for related work discover that someone already had this idea, often under a different terminology. And I consider it a good sign to have ideas that
2
1
7
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
While there were ideas to restrict control-flow before CFI, CFI was formalized and implemented in academia then iterated on several times. We try to explain the situation and give an overview in our survey: nebelwelt.net/publications/f…
2
4
9
as for 'formalized', it's wrong too, if you read and understand their model, it's basically a tautology (assumes a model in which control flow violations aren't possible then "proves" it). btw, where's any mention of RAP (or FPValidator for that matter) in your 'survey'?
3
3
So lots of bad papers come out of infosec academia, but certainly, there is a lot of good stuff coming from academia. With the exception of Spectre/Meltdown, the side channel space is completely dominated by academia. CFI started in academia. etc.
3
1
18
CFI didn't start in academia but with yours truly ;). hint: pax-future.txt
2
6
1
22
almost 6 years later STRUCTLEAK comes to Windows:
Please join the Windows kernel in wishing farewell to uninitialized plain-old-data structs on the stack. As of today's WIPFast build, any Windows code compiled with /kernel also gets compiled with InitAll, a compiler security feature that initializes POD structs at declaration.
1
10
1
34