zkldi

This is one of the funniest posts on Hacker News

Hey, good to hear that it was just YouTube holding the comment. I really thought you deleted it which was audacious. I'm now much less mad :P.

I think we can set up something interesting here, I'd be down to set up a little "PHP2Shell Olympics" as we change preconditions and see how well the exploits fare. I am pretty sure our opinions of "this can be exploited, and LLMs can aid a rapid exploit of previously-complex ASLR nonsense" and "it's difficult to do memory corruption over the internet; php2shell is not a log4shell moment" are mutually compatible.

My contact details are on the bottom of the blog post.

But the Dutch government websites do generally (I hope) have users, which is one of the ways the "I need to hit the same php worker, uninterrupted, for about 10 to 30 seconds while absolutely no other traffic hits the site AND I can isolate the one worker from the pool" approach to exploiting fails.

Luck is not a security boundary, they should patch their servers, everyone should. It's not a good thing to have shitty memory management on your server.

However, is this really that exploitable in real world conditions? (no)

My favourite actively unreleased 0 day exploits are the ones that are released, 5 days old, and allegedly so trivial to exploit it costs $5 in tokens.

No, I will not spend $5 in tokens to claim your $1000 bounty. My $5 exploit is worth more than $1000. Thank you very much.

Hey, you're leaving out that nginx's default is to cap at 1m, btw.

Hi LiveOverflow, I'm Elias and you made a video reply to my blog post. Why did you delete my comment on your video? (EDIT: Youtube fucked with my comment, not LiveOverflow! Editing to put this at the top of the thread so that it is read)

Your second exploit that you slopped out - after someone pointed out your first exploit depended on reading the container's memory via `/proc/pid/..` - also depends on an extremely contrived thing outside of a lab.

To get around the fact that you need to hit the same php worker over and over again (this is another way the LLMs were stacking the deck in their exploits; so many of the exploits online had php running with one worker - which is an unbelievably unrealistic precondition. That, and with ASLR off, lol.), you hold WORKERS-1 connections open indefinitely (lol) and then need to sequentially, and stably, hit the same php worker for 10-30 seconds.

Of course, luck is not a security boundary, everyone should still patch their servers.

But how is it a realistic precondition to have a server in which you are the *only* person making requests for 30 straight seconds? Even a single googlebot pinging the website would fuck your heap grooming up, let alone regular users, or another person trying the exploit out! Similarly, Holding WORKERS-1 connections open indefinitely so that you can isolate one php worker is extremely unrealistic in practice.

Yes. this is a vulnerability, it is bad. No, it is not easy to replicate in real world conditions. The LLM gets you an "exploit" locally. How on earth did you not extrapolate from the LLM decieving you the first time, and think for some reason the second time the conditions were 100% truthful? Did you even read the stdout from the exploit you wrote?

I really like your work man, you're a great inspiration, but what the fuck are you doing? And why delete my comment pointing this out?

Brilliant thread. Glad you did this before I did.

Hilarious to see people suddenly furtive about this easy exploit. Thanks.

Hi, I wrote the blog post and wish I'd just written your exact words instead.

A lot of the lab PoCs still use contrivances (ignoring the ones that are disabling ASLR or just inserting `vulnerable.php` files on the server) that you don't really get in the real world - even the requirement of having to heap groom the same PHP worker repeatedly and sequentially is quite hard to exploit if the website has traffic. (this is why some of the slop PoCs reconfigure apache to have one worker, or pin WORKERS-1 with infinitely long requests).

This is in stark contrast to other, more severe vulns that the internet has seen (and will see in the near future) where there's effectively a blank cheque to fuck anything that is unpatched. This is not a blank cheque. It is still bad.

This doesnt matter though - luck and statistics are not serious security walls. Patch your servers.

Hi, you haven't looked at the code in your exploit.

Take a look at the php files you're shipping with your "stock" server - theyre pretty contrived, no? fatal.php? producer.php boom() str repeat X 32?

You use that to get the constants for the RCE, but without that information you're in trouble. How transferrable are these constants? Do they work with any config changes?

Again, the vuln is real and you should patch, but an exploit is not easy; this is not log4shell/heartbleed etc.

I find it offensive that your blog is named after thelastpsychiatrist when the writing is not even close in quality. Come on man, I expected you to start swinging. Are you building an agent tunnel? Get outta here.

Expands into a document for _who_ to read? another LLM to re-compress?

It's baffling you people are in control of such a strong product when you are obsessed with this intellectual pornography; wow - look at how smart it made my thoughts look (n.b. look, not read). Don't look too close. And certainly don't ask me what it means.