The RCE exploit is application dependent: it requires exploitable PHP code already deployed in the server. However, that exploitable code path is widely deployed by the most popular PHP software: WP, Drupal, Joomla, etc, so in practice most PHP deployments are vulnerable to the RCE attack.
Note that use-after-free would be prevented in memory-safe languages such as Java, Go or Rust.
Great, so show us a working exploit.
Buy 5$ on deepseek and have it write a script to grind out the right offsets to use for the most popular docker images.
I got it working just now; shell on any docker image i pull.
GG this dumb ass blog-post and thread.
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?
The question we are getting at is - is this easily exploitable? I haven't see evidence of that.
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 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.
To be fair, C has simplicity as an attractive feature (compared to other languages) but being memory-unsafe is unacceptable, so we need either memory-safe C or stop using it.
There are also hardened malloc/free implementations for C based runtimes. Of course none of that is perfect, the famous heartbleed exploit for example bypassed any outside memory protection as the library agressively reused already allocated buffers, none of the languages you named would protect against that.