First of all, thanks for your response.
> This rarely helps. Most of the nice-to-exploit bugs were in older codes, which weren't using STL containers.
While I agree with this, is not modifying those code to use STL containers much cheaper than rewriting into an entirely new language?
> Shadow stack is meh.
Are you referring to the idea of shadow stacks in general or a particular implementation of them?
> For example, for browser renderer without sandbox / site-isolation etc
I may be wrong, but I think you are referring to JIT bugs leading to arbitrary script execution in JS engines. I don't think memory safety can do anything about it because those bugs happen in the binding layer between the C++ code and JS scripts. Binding code would have to use unsafe code anyway. (In general, script injection has nothing to do with memory safety, see Log4j)
> Uh, I'd guess, half or more of that.
I mean, if you are after RCEs, don't CFI and shadow stacks halt the program instead of letting the CPU jumping to the injected code?
Now, let me get more specific - can you name one widespread C++ exploit that:
* would have happened even if the above mentioned mitigations were employed.
* would not have happened in a memory safe language?
> This rarely helps. Most of the nice-to-exploit bugs were in older codes, which weren't using STL containers.
While I agree with this, is not modifying those code to use STL containers much cheaper than rewriting into an entirely new language?
> Shadow stack is meh.
Are you referring to the idea of shadow stacks in general or a particular implementation of them?
> For example, for browser renderer without sandbox / site-isolation etc
I may be wrong, but I think you are referring to JIT bugs leading to arbitrary script execution in JS engines. I don't think memory safety can do anything about it because those bugs happen in the binding layer between the C++ code and JS scripts. Binding code would have to use unsafe code anyway. (In general, script injection has nothing to do with memory safety, see Log4j)
> Uh, I'd guess, half or more of that.
I mean, if you are after RCEs, don't CFI and shadow stacks halt the program instead of letting the CPU jumping to the injected code?
Now, let me get more specific - can you name one widespread C++ exploit that:
* would have happened even if the above mentioned mitigations were employed.
* would not have happened in a memory safe language?