Yeah? You got it working? Then why can't it pawn my webserver running php-5.6 and drupal 7? Should be pretty easy, those are both unpatched ancient versions.
Probably because you're too cheap to spend $5 on DeepSeek tokens? Its specifically labeled for a 8.4 version IIRC.
I'm not sure what your question is or what you're getting at. The only time-sink for general purpose exploit is to churn through previous PHP versions to get the right offsets/struct sizes and common memory configurations.
Do you think security is done by running obscure configurations?
I don't understand what you mean with demonstrate. You want me to post the php2shell for their set-up?
Its not "if" this is easily exploitable; its what you two want to define as easily exploitable.
It already is by my definition - that is also the clear majority opinion (unless you want to appeal to specific authorities that agree with your alternative definition).
As far as i can tell i've already posted more than enough proof with that github link for anybody that is a bit curious and with passing knowledge of exploits.
I'm stuck guessing at what more you want or expect of me in a random HN thread. I'm inclined to just wait 24h and there will be a public version that hacks this hypothetical php-5 set up as well.
You both clearly have a different definition of easily exploitable; and until somebody tells me what that definition is and what background knowledge I can assume I have very little I can do here except guess at what you're both ignorant off.
> I don't understand what you mean with demonstrate.
I was quiet clear I thought. I wanted a working exploit. Someone to demonstrate that my (or someone else's) server can be hacked with this exploit. So far what you've provided is a tightly constrained lab example where you have to control the amount of memory given to a server (significantly I might add), modify the apache and php configuration way outside sane values (exactly 1 worker, 8MB memory limits), have knowledge of the exact php build used on the server and how it is being ran (mod_php here).
In a standard webserver, you're not going to know any of that or have control to make any of that happen. Nobody is running a PHP website on a 128MB ram VPSs, nobody is running with exactly one apache worker. You're not going to know ahead of time which build of php they're using, or if they built from source.
I had to keep guessing at how much you actually know about this stuff, but given you brought up the workers as a constraint means you are either completely clueless and/or have absolutely 0 intention to think for yourself.
No 'proofs' like "demonstrate on someone else's server" or explanation of the exploit chain will ever be enough to convince you.
You dont want "a working exploit" - and we could have all saved some time if you were honest: You don't know what you're talking about and only after being given a complete exploit you can run against any target will you consider it easy by your standards.
Good talk. By your definition of easy, i can easily agree this exploit is not very easy. Though the settings dont matter/can be bisected remotely, you're right that - afaik - nobody has figured out how to avoid guessing the compile settings and version. Thus compiling it with custom settings is going to keep you safer in practice, while using a container is more dangerous.