Of course, with a memory-safe language, W^X is not a needed mitigation. With runtime compilation, it is, as illustrated here, even in the way.https://twitter.com/TheMichaelBurge/status/978381073506643968 …
We're talking about a very specific case here: having Racket in memory. Now w.r.t. CFI, there are two subcases: 1. CFI stops the attack. W^X is not needed. 2. CFI doesn't stop the attack. Attacker calls scheme_eval_string(). W^X doesn't stop the attack.
-
-
Or as a corrolary: if you can call eval(), W^X is security theater.
-
It can essentially always be bypassed even without eval(...) or an interpreter though. It only puts up a small barrier to exploitation, but that can be very valuable when considering how difficult it can be to make reliable memory corruption exploits.
-
If eval() isn't there, it increases effort for the attacker, yes. With eval(), it doesn't make any difference at all.
-
An attacker needs to find the address of eval and a function pointer / return address to overwrite with it along with setting it up to properly pass a pointer to their code. It's not that much different from them being able to call system(...) in libc to run /bin/sh code.
-
If there's writable machine code, interpreted code or bytecode in memory for them to simply overwrite without needing control flow hijacking, that's way easier. If they have arbitrary read/write, they've won, but these mitigations aim to make it take longer to put it together.
-
There's both bytecode and a JIT. So yeah, plenty of surface.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.