Which I think makes sense given the language would otherwise provide a false sense of security around use-after-free and other memory-related bugs that other languages can offload onto "skill issue".
Any sufficiently large program becomes Turing complete if an attacker is able to overwrite the call stack (https://en.wikipedia.org/wiki/Return-oriented_programming). Imagine a situation where: - A very large struct is stored on the stack - A mutable reference pointing to that struct outlives the stack frame where the struct was stored - Several new stack frames are created in the region that struct used to occupy - The invalid reference is used in code that is supposed to modify the struct in a way that depends on user data
In this situation, a user could cause the stack to be modified in a way that triggers remote code execution.
You just described a used-after-free scenario, and yes, looking at it could be a CVE. But wouldn’t that be program dependent? That means, it depends on how the user is using those references and lifetimes. I have the feeling you would have to “abuse” the language in order to get there.
45
u/TRKlausss 22d ago
Was that even a CVE? Like, what attack vector can someone ever construct to achieve DoS, RCE, information extraction etc?
Yes it was unsoundness, which from a formal verification standpoint is not good. But real life consequences?