Comment by TekMol
18 hours ago
Many here call for an earlier release of the patch.
But it is not clear if releasing the fix early would make the damage smaller or larger.
Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
There is no way to coordinate the whole world on an earlier time. I would guess the number of people who have to patch their instances is in the hundreds of thousands.
Everybody who actively watches the topic already has the option to shut down their instances.
So ringing the bell and getting as many people as possible to shut down their webservers now and patch at 14:00 might be the best in terms of damage minimisation.
By the way, it is not enough to just "shutdown -h now" and then later restart and "apt update && apt upgrade". The moment the machine comes back, it can get hacked. So you should make sure the webserver does not start after the next boot. For Apache this would be something like "rm /etc/systemd/system/multi-user.target.wants/apache2.service" and then after patching recreate the symlink via something like "ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/apache2.service".
There are several PoCs, and according to Cloudflare, the vulnerability is already being actively exploited: https://x.com/dok2001/status/2112811965735202970
> Everybody who actively watches the topic already has the option to shut down their instances.
In theory. In practice, many can't just decide to shut down their service for a few hours.
Guess they can decide to let random hackers all over their server instead.
Is there any major service that has gone offline? Why is Wikipedia still up, did they manage to mitigate? What about Etsy?
WP sites like whitehouse.gov, TechCrunch, Time?
I don't see anything well known being down.
7 replies →
We just turned off uploads like they suggested to do. Our decision isn't "to let random hackers all over [our] server".
5 replies →
There's an exploit freely available already, by the way. You can't contain things like this.
If not, you or our agent could build an exploit from the information that's already out.
Are you 100% sure? I have tested 2 PoC's against my dev environment, no luck so far. So I am not sure if there is working exploit already.
I have not seen confirmation that the exploit is for the bug that is going to be patched.
It seems the published exploit can be easily prevented by filtering out multipart post requests. So people actively watching the situation can already prevent that issue by filtering those.
I was able to cook up something in less than 10 minutes and tested many sites. There is a page with enough explanations to do it.
Did you successfully run a RCE test, or only a vulnerability check? So far all write-ups and PoC's i've found fail to "cash in" on the RCE part.
3 replies →
fwiw it looks like the patches were made available early on chainguard
https://images.chainguard.dev/directory/image/php/versions
How does it work that some service that most people never heard of distributes (paid) images with alleged fix for vuln 24h before official vuln fix/image is available? Seems somewhat shady.
thats chainguard’s entire value prop (they are quite well known in this sphere)
1 reply →
Is there a public announcement? I can only see PHP 8.5.11 images, but having a recent build date is not enough to say they are indeed patched.
context: https://news.ycombinator.com/item?id=50176735
I can almost confirm a Wordpress site I manage was attacked with this. Oct 5th updated it to latest php and Wordpress. Oct 6th it was exploited with a web shell exploit
On the other hand: it is Wordpress, who knows how many other exploits could be hiding among the dozens of plugins it likely has installed?
this is not a web shell exploit. This goes to container shell level. Very different scenarios.
What ultimately ended up happening?
Yeh this isn't that.
systemctl mask/unmask
> Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
I think that this made sense a few years ago but in today's world it is so feasible to give an LLM a hint and throw some cash at it to find an exploit that I don't think this calculus makes sense anymore.
> Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
No matter the excuse, the security issue must be fixed. Anyone trying to delay this is not acting in good faith. I understand your rationale but that does not excuse you from being labelled as such too.
We should live in the age of open source AT ALL TIMES. No exceptions, for anyone, no matter the reasons. And that includes those who want to withhold code or patches.
You might disagree with them, but I am pretty sure the php maintainers are acting in good faith.
Honestly, leaving everyone vulnerable and sitting on the patch while the exploits are out in the wild (i.e. no more use of delayed release) is hard to stomach.
A lot of people are going to do the math on migrating. Bugs happen everywhere. Leaving the community out in the cold and only supplying the corporate sponsors doesn't.