This is one of the funniest posts on Hacker News
1,734 karma · joined March 10, 2021
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.
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)
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.
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?
Hilarious to see people suddenly furtive about this easy exploit. Thanks.
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.
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.
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.
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.
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
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.
"Provably Correct Axiom" is nonsense. An axiom is unprovable.
Just "provably correct" would've been fine. This chess stuff is hilariously pretentious.
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.
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.
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.
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.
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.
Like in TPK, 0/0 is Infinity and in IJ, Pemulis explains differentiation completely incorrectly, also that stuff about the mean value theorem is irrelevant?!?
Still one of the greatest authors; deep technical correctness is more of a Pynchon thing.
I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.