Right. So can you elaborate why would attacker's arbitrary read/write break RAP's CFI? Shadow-stack should also always remain read-only. In RFG it was only hidden but still writable which lead it indeed to be not effective, but this isn't true for CET-like shadow-stack.
1
1
Arbitrary RW means I can have a callchain that goes from C++FuncA -> JITedCodeB -> C++FuncC, and I can then make the JIT engine garbage-collect JITedCodeB and put different code there. Not violating any CFI constraints, but executing arbitrary code.
3
6
1
24
Ah no, the return-after-free (as I like to call it) idea was entirely your own. My sole contribution was to drag you into a meeting.
1
2
I remember this being very much developed in ping-pong, so I will continue to attribute 51% to you :)
1
4
@grsecurity
ROP attacks return flow. So saying that there is no effective mitigation against ROP might not be entirely wrong by Intel.
CET shadow stack does address ROP in fine grained manner and deterministically. And assume arbitrary read/write primitive in attacker hands.
/1
2
@grsecurity
In your analysis you mentioned that attacker can use RELRO pages and perform writes to manufacture RO but dirty (thus shadow stack) pages.
CET prevents that by faulting ;
CR0.WP can't be cleared if CR4.CET = 1. Setting CR4.CET while CR0.WP=0 will fault.
/2
3
RELRO pages have nothing whatsoever to do with CR0.WP. it's a pure sw construct that through syscalls ends up creating the exact pte rights that also mark shadow stacks (unless said sw construct takes care of preventing that, hw can't do anything about it).
Jun 17, 2020 · 8:13 PM UTC
1