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.
> 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.
Thanks for the explanation. Maybe I don't totally understand.
And yeah, obviously it's still dangerous to have arbitrary code running with PHP's privileges.
Just one thing: With mod_php, those httpd processes are spun up on demand. After that the memory is released to the system, right? There's no master Apache webserver process holding all those addresses.
Just for clarity, I took the OP's point to be that the only way this could be used to escalate privileges would be if there were existing scripts on the server with credentials that PHP itself could be made to exec() ...but... if you know a process is going to be spun down and no longer holds a pointer to the memory you're writing to, couldn't you theoretically write something that might be picked up by the next process? Or is that always formatted by the next process' vm?
Appreciate your patience, I'm not a low level coder.
It’d be redundant for me to write up the whole explanation here, but the short version is that every process has its own memory space, provided in a clean state by the OS, that other processes can’t read from or write to, regardless of pointer values. The same pointer value in two processes doesn’t refer to the same memory unless there’s specific coordination. Keywords you can use to read more about the long version on previous Wikipedia link.
> Or is that always formatted by the next process' vm?
So yes, that’s sort of how it is.