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?

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.

How is this a good reality check? This is an AI generated article?

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.

Guys. Guys, you got it all wrong. We don't want to ban open-weight models!

We just want to ban the competition guys! Very different.

--

The ridiculous anthropic/openai strategy of selling shovels at a loss in a gold rush isn't going to play out, and the hilarious thing is that these AI companies are going to create tons of value and _capture none of it_.

Their only path to profitability is if they get to capture it and they're going to do everything to do so. Put it this way: *all the blog posts that Anthropic and OpenAI are putting out are DESIGNED to scare you so that you let them capture the market*.

...and "distillation attacks" (hilarious framing of "saving the output of our models")... Whatever.

Hi leerob,

Where is the support thread?

I have ticket T-D95851 at the moment, if you could get someone to resolve it. I do not want to use cloud agents.

Thanks

zk

AI slop article. It wasn't just X. It was Y.

Also, $500/mo for 64GiB of RAM and 16 mystery meat CPUs. LOL! You guys are all being ripped off and you don't even know it.

All of these replies are AI slop.

AI slop article, sorry.

It's just not what the word axiom means nor how anyone uses it. An axiom is unprovable by definition - is it a thing we accept to be true because it is useful to do so (e.g. there exists an empty set)

"Provably Correct Axiom" is nonsense. An axiom is unprovable.

Just "provably correct" would've been fine. This chess stuff is hilariously pretentious.

Jesus Christ. We've made the psychosis machine.

I just don't understand how this can be this slow. What on earth is it doing to get 193 requests per second on static, cached content?

The article doesn't dig too deep into this sadly, rather just accepts that it's slow and uses a different tool.

But seriously, this is responding to a request with the content of a file. How can it be 100,000x slower than the naive solution. What can it possibly be doing, and why is it maxxing out the CPU?

If no-one else looks into this, I might get around to it.

But this isn't even true, and NextJS is well into egregiously complexity. Remix was an alternative option in the space that is now deprecated in all-but-name for React Router v7, which (for those just tuning back in), react router is now a framework.

If you wrote your app in NextJS 2 years ago, you would already have to rewrite chunks of it to get it to compile today. These tools are NOT solidified, they are releasing breaking changes at least once a year.

The blog post you've linked doesn't justify what you've said about it at all.

In the netflix blog post they're complaining about increasing latency over time because they have a function that *reloads all express routes in-memory* that didn't properly remove all the previous routes, so the routes array got bigger and bigger. That's not a fundamental problem with express[1], that's an obscure (ab)use case implemented wrong. Hardly a damning indictment of express.

> This turned out be caused by a periodic (10/hour) function in our code. The main purpose of this was to refresh our route handlers from an external source. This was implemented by deleting old handlers and adding new ones to the array. Unfortunately, it was also inadvertently adding a static route handler with the same path each time it ran.

[1]: Admittedly an array is not the "best" data structure for routing, but that absolutely wasn't the performance issue they were having. Below a couple thousand routes it barely matters.

Extremely misleading title.

The software in question is the winning entry in a hackathon from 2020: https://github.com/DevrathIyer/ballotproof

Inside that repo they have a script called `generate.py` which generates ballot test data.

Look at it for yourself: https://github.com/DevrathIyer/ballotproof/blob/master/gener...

It's a ~100 line python script that generates some test data. The last commit on is as naive as "hope this works".

What a horrendously misleading title. It's just some kids making something with OpenCV to scan images. Ridiculous.

I'm in the same boat. Where did you move to?

An interesting one is "bread" to refer to money; I believe it comes from cockney rhyming slang. Bread and Honey = Money.

cargo is a bad example as it's universally `cargo build`.

Make on its own is great but most of the time I've worked with C projects it's been cmake/autotools + global pkg installs, which you Do have to frequently look up.