I might be confused about what clang CFI is doing there differently, going to read up on it. The CFI implementations I'm familiar with are mainly concerned about jumping into the middle of a function body for ROP primitive building.
-
-
Replying to @andreasdotorg
That's Microsoft CFG and what Intel CET do for function pointers (along with not allowing function pointers to call functions that are identified as not indirectly callable) but Clang CFI is type-based.
2 replies 0 retweets 1 like -
Replying to @CopperheadOS
Just noticing: if any of these control flow mechanisms stop an exploit, they do so regardless of whether W^X is active.
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg
In the more narrow cases where they actually stop a vulnerability from being exploited, they don't really need that, but for powerful primitives like arbitrary write they aren't much good at making it harder to exploit if the attacker can just overwrite executable code.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS
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.
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg @CopperheadOS
Or as a corrolary: if you can call eval(), W^X is security theater.
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg
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.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS
If eval() isn't there, it increases effort for the attacker, yes. With eval(), it doesn't make any difference at all.
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg
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.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @andreasdotorg
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.
1 reply 0 retweets 1 like
There's both bytecode and a JIT. So yeah, plenty of surface.
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.