By corrupting memory and causing the CPU to jump from the intended instruction to a different one controlled by the attacker, at which point their instructions control what your process does next. Getting shell does not mean getting it to feed a spicy string to system(), it means tricking something in the process into overwriting memory with bytes that, if read as instructions, tell the CPU to make a system call to spawn a different process running arbitrary code.
You could do that to an internet-connected toaster with a JPEG. The system() function has nothing to do with it.
What is lower than what? This exploit causes the flow of control to reach zend_call_function with the argument "system". It works at the PHP level and having disabled that function is an absolute defense against the exploit.
It isn't 1998 any more and you can no longer just inject shell code on the heap.
By corrupting memory and causing the CPU to jump from the intended instruction to a different one controlled by the attacker, at which point their instructions control what your process does next. Getting shell does not mean getting it to feed a spicy string to system(), it means tricking something in the process into overwriting memory with bytes that, if read as instructions, tell the CPU to make a system call to spawn a different process running arbitrary code.
You could do that to an internet-connected toaster with a JPEG. The system() function has nothing to do with it.
I can guarantee you that it's not because someone left system() enabled, it's much lower than that.
What is lower than what? This exploit causes the flow of control to reach zend_call_function with the argument "system". It works at the PHP level and having disabled that function is an absolute defense against the exploit.
It isn't 1998 any more and you can no longer just inject shell code on the heap.
The current PoC in the public gets there via that method, and even then you don't need to call system() alone to cause hell on a host...
2 replies →