Giving the impression that you buy this new Intel processor and your problems are solved -- you don't get better than that coarse-grained forward edge check without significant static analysis and source code changes, something that was already done for the kernel in 2014 w/ RAP
Conversation
For userland, there will be a rude awakening when people realize how much there is to do ( spent a lot of time on it), which slapping CET support in the compiler does nothing to address
2
3
... and then you're still stuck with a browser & a JIT engine, and all your CFI goes out of the window if an attacker gets arbitrary r/w first.
2
1
9
I mean, reality is: Most pwnage happens through the browser now, and CFI is simply not effective in the presence of all mainstream JITs.
2
4
16
When using out-of-process JIT (As in Edge), the JIT code is RO in JIT process. Thus, CFI hashes compared on fwd-edges and the compare itself are in RO mem. i.e. XFG/RAP fwd-edges still work. Same is true for RAP backward-edges (ret hashes and compares are in RO memory as-well).
1
I was not talking about writing to +x pages. If any +X address space is ever reused -> break.
1
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
8
25
In short: CFI is bunk in an environment with a JIT that ever reuses +x address space.
3
1
9
Oh cool. You are right. I haven't thought about that attack. Thanks! :)
2
1
Now that Edge is based on Chromium, it also doesn't have that feature anymore. You can pass `--js-flags=--jitless` to Chromium (or Edge) to disable the JIT to only use the interpreter. It's compatible with ACG, PaX MPROTECT, SELinux !execmem, etc. Still, there's an interpreter...
Consider a Python application. If an attacker has arbitrary write, they can make the interpreter run their own bytecode. In that case, the bytecode is fully trusted. Even if a JavaScript interpreter doesn't directly trust the bytecode it generated, an attacker can mess with it.
1
4
That was one of my pet peeves with out-of-process-JIT'ing -- the only "safe" API to do that is pass the unparsed JS text.
1