A memory safe language still has a substantial trusted computing base of potentially memory unsafe code. Those mitigations don't lose their value. Making it trivial to exploit a heap overflow vulnerability like this once it's found isn't a great plan: https://github.com/rust-lang/rust/blob/c661e385fd81afef808f414867cc44a6c897195e/src/liballoc_system/lib.rs#L332-L333 ….
-
-
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.