ynwarcs
commented
2 weeks ago The PoC demonstrates a memory corruption, even though it doesn't achieve arbitrary code execution. In its current state it's indeed only a DoS (though it could leak kernel memory back to the attacker with some tweaks, if the firewall is disabled). However, memory corruption bugs are treated as allowing code execution in any serious product nowadays, even if they're unlikely to be exploited. e.g. you can check chromium or firefox vulnerability reports.
I would treat this vulnerability as somewhat likely to be exploited, as the memory corruption primitive is pretty nice. Microsoft even treats it as "more likely". The fact that the PoC almost immediately crashes the system upon memory corruption is because we're causing the corruption num_tries times, which is 20 by default for demonstration purposes. It would be a pretty annoying PoC if it caused a corruption that was only caught by the debugger a few minutes later. If you change num_tries to 1 and re-trigger the vulnerability, you'll hopefully see that the system is definitely not guaranteed to immediately crash following the corruption.
Folks have managed to achieve ACE with more constrained primitives in the past, so I would suggest treating this as a true 9.8.
yuziiiiiiiiii
I feel like this is an important point that your POC potentially proves. This vulnerability should not be labeled RCE if there is no possibility to execute code with a payload (i.e. get a shell to the remote system, or get it to execute code WITHOUT crashing). If the payload can only trigger a crash, it should be labeled as a denial of service vulnerability. This is critical so that security teams can correctly address the risk of this vulnerability.
Can you confirm that this is, indeed a DoS vuln, not RCE?