If a system is accessible by someone else, it is inherently insecure and needs to be hardened.
And in a case like this, with so many exploitable PHP boxes out there for attackers to choose from instead, certainly buys you some additional protection.
I wouldn’t choose to roll my own on the day I needed it though.
Relying on this patch, you're only protected against these specific CVes, but in general a proxy can protect you from more. It's strictly additive security, right?
And if you can't or won't patch your PHP, this is strictly better than getting pwned and having your PHP-FPM execute arbitrary commands. That's as bad as it gets, and you better hope that Linux user permissions can constrain it, but your apps are basically gone. PHP-FPM even allows PHP to overwrite .php files, meaning next time they are hit, it's completely arbitrary code that persists.
As a side note: https://qbixserver.com is a project I started several months ago, that is a pure PHP server without needing nginx, and it forks after loading your classes, instead of preforking like php-fpm. It's not vulnerable to php2shell, and it is able to rewrite php code on the fly when it loads it, to make it more safe. It does things like disallowing your php scripts to write to .php files, and it makes require($filename) check that $filename actually ends in .php ... a lot of stuff like that.
The security added by this proxy is strictly additive, it can't make things worse. This proxy can be run by a Linux user with no permissions at all, so it just transforms input. Can it have a sleeper code that transforms input in a way that causes your PHP to do something even worse? Well, this is why you should point Claude at the repo and ask it if it has any backdoors. It's completely open source and GitHub actions has been used to build the binary. So I guess if you don't trust GitHub, you can also compile it yourself, but then you're trusting GCC. (Ken Thompson has an interesting talk on Trusting Trust of compilers, from 30 years ago.) But at this point we're way past what people usually are concerned about.
Except if this code contains bugs that lead to another RCE.
> Well, this is why you should point Claude at the repo and ask it if it has any backdoors.
When do people understand that LLMs are no oracles. Just because some LLMs tell you the code is safe or has no backdoor doesn't mean it is true.
1) The proxy is open source and much simpler than PHP runtime or a web application. Its code only takes input and generates output. It is basically a pipe. It has no other capabilities to exploit.
2) The operating system, such as BSD or Linux, supports running processes under a user and enforces limits on that user. So you just jail this proxy — since it has one purpose. Unlike your application, which may do many things and you can’t restrict it, it may become a confused deputy
What this has taught me is that we should decouple as much as possible into microservices, so that we can properly sandbox each service, and that way we have chokepoints.
if it tells me there is a backdoor, and shows me how its used, i can be pretty sure that there is one though.
if claude cant find the backdoor, chances are that claude cant find a backdoor. its still not an oracle, but that is still useful feedback for updating priors
No, the proxy itself may have memory vulnerabilities that could give attackers remote code execution capabilities.