| ▲ | noduerme 2 hours ago | ||||||||||||||||
OP seems to be implying that there's no way the UAF bug could be used to run arbitrary code with higher privileges than PHP itself, on a vanilla installation. I couldn't divine that from reading the CVE. Is that true...? Is that why you'd need PHP to exec an existing file or something? Or is that assumption just based on the fact that the PoCs so far rely on nerfing PHP? If the latter, it's a bit ironic to complain about everyone's judgment skewing toward Claude's while using Claude-generated code not doing it as circumstantial evidence that such a thing can't be done. I'm no expert on UAF exploits. I guess one thing I'm wondering is whether the pointer to "freed" memory in this case is still pointing to memory reserved by the system for a PHP process, or if it's some address that's truly free and could be picked up by another process. | |||||||||||||||||
| ▲ | minitech 2 hours ago | parent [-] | ||||||||||||||||
> or if it's some address that's truly free and could be picked up by another process This isn’t a thing; virtual memory (https://en.wikipedia.org/wiki/Virtual_memory) is very old, and Linux has never not used it. It takes a separate vulnerability (a “local privilege escalation”) to do what you’re getting at. (However, those are plentiful, and arbitrary malicious code with PHP process privileges is often already catastrophic for a web service.) That said, > OP seems to be implying that there's no way the UAF bug could be used to run arbitrary code with higher privileges than PHP itself No, nowhere does the article imply that at all. | |||||||||||||||||
| |||||||||||||||||