I am seeing a lot of words like "unconditional" thrown around but I remind that defense in depth is a thing and you can practice it, or should have been practicing it. You can, for example, disable the `system` function of PHP altogether. You can also arrange for your PHP to be running in a situation where there's no shell, or any other program, to exec. Or for that matter a filesystem.

▲

Operyl 7 hours ago | parent | next [-]

It's a RCE bug, it does not matter if you disable php functions. It's not arbitrary PHP execution, it's an exploit chain resulting in arbitrary code execution.

▲

afdbcreid 7 hours ago | parent | next [-]

Indeed, an attacker theoretically can access anything the PHP process has permission to access. However even without limiting permissions (also a good idea) that means the simple/published exploits won't work on your server, and there's a high chance criminals will look for other targets, assuming you're not targeted.

	▲	reorder9695 3 hours ago \| parent [-]
		Presumably this makes SELinux enabled distros like fedora are significantly less vulnerable, as the PHP process can only access files in a few contexts?

▲

jeffbee 7 hours ago | parent | prev [-]

You know how "resulting in a shell" works?

▲

bulatb 6 hours ago | parent | next [-]

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.

▲

Operyl 7 hours ago | parent | prev [-]

I can guarantee you that it's not because someone left system() enabled, it's much lower than that.

▲

jeffbee 5 hours ago | parent [-]

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.

▲

Operyl 5 hours ago | parent | next [-]

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...

▲

jeffbee 5 hours ago | parent [-]

The point of this thread, and of defense in depth generally, is to limit the scale of "hell" and to trivialize the impact of "on the host".

	▲	Operyl 5 hours ago \| parent [-]
		Look, at the end of the day, every major security researcher is going "oh shit" and no amount of tweaks to your configuration is going to limit the blast radius in a way that will actually matter. You're going to need to update PHP, that's the _only_ solution to this problem.

▲

5 hours ago | parent | prev [-]

[deleted]

▲

calvinmorrison 7 hours ago | parent | prev [-]

no idea why this is downvoted. PHP runs typically on linux machines. If you depend on a language feature to prevent 'exploit' and don't utilize the operating systems features to limit access to data.

Shell access is not good, but in many places that wouldn't be the end of the world either.

Rethink your strategy

	▲	Operyl 7 hours ago \| parent [-]
		If your PHP application accesses a database, you've got exfiltration, it doesn't matter in this case. Unless your PHP application is just echoing non sensitive data (i.e. rendering md files)...