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 …
-
Show this thread
-
Replying to @andreasdotorg
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 ….
2 replies 0 retweets 2 likes -
Replying to @CopperheadOS
Umm, returning to scheme_eval_string makes any control of instruction pointer in a process instant easy code execution, W^X or not.
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg
An attacker being able to overwrite a function pointer or return address doesn't mean they can run any code in the process. They need to choose code that the CFI implementation permits calling from there and they need to be able to point it at the dynamic address of that code.
1 reply 0 retweets 1 like -
Replying to @CopperheadOS
scheme_eval_string is a legit entry point. Your CFI won't save you.
1 reply 1 retweet 1 like -
Replying to @andreasdotorg
Not quite sure what you mean by that. Clang CFI will permit calling it if the type signature matches the calling site, which it might. An attacker will often only have control over function pointers in the heap via use-after-free, etc. and those often have restrictive types.
2 replies 0 retweets 1 like -
Replying to @CopperheadOS @andreasdotorg
There are better CFI implementations than type-based CFI + preventing calling non-indirectly callable functions like Clang does though. Certainly agree that having a bunch of writable bytecode, etc. makes exploitation of memory corruption bugs much easier, and they still exist.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @andreasdotorg
Deployed mitigations for memory corruption bugs like ASLR + W^X + CFI aren't great but they still often manage to turn exploiting bugs into something that takes a week or two of hard work instead of an hour. Even if 90% of code becomes memory safe it's important to do better.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @andreasdotorg
Can do away with dangerous tools like C and C++ without bringing new problems like making the remaining memory corruption bugs easier to exploit and having pervasive dynamic code execution bugs. Logic errors involving dynamic code exec are way easier to exploit too.
1 reply 0 retweets 0 likes
Prediction here: we will see formally verified language runtimes within ten years.
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.