Remix.run Logo
▲ Gigachad 13 hours ago

The demo video has been going around Twitter today and apparently the proof of concept is privately being shared around too. The video shows pasting something in the URL and then gaining a shell on the server. It looks completely catastrophic.

I think the best course of action is to just shut your server down before the patch goes live and then bring it back after you have patched.

▲ndiddy 8 hours ago | parent | next [-]

The URL is to show the effects of the exploit. The person's running a python script that runs the exploit and then makes the PHP installation execute an arbitrary shell command. The proof of concept involves writing "pwned" to a publicly accessible location on the web server, then they refresh the browser pointing at the URL to show it's been written.

▲archon810 11 hours ago | parent | prev | next [-]

https://x.com/k_firsov/status/2112641845926989944

▲philipwhiuk 11 hours ago | parent | prev [-]

This is gonna rinse so many LAMP WordPress installs where the PHP version is either not getting a patch or the hosting is managed by the user via a contractor or the hosting is managed by a company with a fleet of custom servers etc etc.

▲bigbuppo 4 hours ago | parent | next [-]

It's sad how many wordpress installs haven't been patched in a decade. they're so old even new exploits aren't supported.

▲dylan604 4 hours ago | parent [-]

ha! Who knew ignoring critical updates and continuing to run deprecated software while kicking the can down the road while focusing solely on building new features would turn out to be the best security policy after all.

▲geerlingguy 24 minutes ago | parent [-]

That was how a cluster of Java servers at a former employer avoided the Log4j vulnerability. Though I think they'd be on at least PHP 5 by now (maybe even PHP 7!), so they can't dodge two bullets.

▲qingcharles 8 hours ago | parent | prev | next [-]

I can think of some really ancient phpBB boards that probably won't ever come back if they get hit.

▲rklaehn 3 hours ago | parent [-]

They might be fine if they are still on php4...

▲Gigachad 9 hours ago | parent | prev | next [-]

We almost need some bot that logs in to every vulnerable PHP server and turns it off to prevent it being properly exploited before the server admin updates it..

▲lioeters 9 hours ago | parent | next [-]

Kindware instead of malware. Just goes around finding vulnerabilities and using them to patch things and improve security everywhere.

▲voxadam 9 hours ago | parent [-]

Benevolent worms.

https://www.schneier.com/blog/archives/2005/12/benevolent_wo...

▲lioeters 9 hours ago | parent [-]

Heheh that's cute.

▲S0y 8 hours ago | parent | prev | next [-]

If people wait too long you could even have the bot use the exploit to update the PHP version.

▲afdbcreid 7 hours ago | parent | prev | next [-]

Nice idea, but I don't think you would want e.g. your hospital to have their systems suddenly turn off.

▲simondotau 5 hours ago | parent | next [-]

Absolutely they do. Off today is better than a ransomware attack tommorrow.

▲pixl97 6 hours ago | parent | prev [-]

Turning off is better than silent data manipulation by an attacker.

▲afdbcreid 6 hours ago | parent [-]

But not than assessment and controlled shutdown or access minimization. Turning off critical systems can result in deaths.

▲jamesknelson 5 hours ago | parent [-]

This feels like it might be the trolley problem in real life.

Turning it off may cause deaths. Letting it get ransomwared may cause more. Do you pull the lever to turn it off?

▲hparadiz 4 hours ago | parent [-]

I can't believe I have to write this out in this thread of all places but there is a way to do this.

You make sure www-data CANNOT write ANYWHERE on disk. Not /tmp/ Not to /var/www/. No where.

Then make sure your sudoers has nothing weird in it.

Finally disable www-data's ability to run basically anything that isn't required for the operation of your httpd or php-fpm et al.

You then harden it further and further until an RCE does not matter because it's incapable of doing anything.

tldr always treat httpd as untrusted.

▲matja 3 hours ago | parent | next [-]

Good advice if you're not using the default PHP session settings, but using default settings this means sessions can't be created. At best, that means no-one can log-in. At worst, it completely breaks the site (for those that depend on sessions even for unauthenticated users).

Also: https://stopdisablingselinux.com/ - SELinux can mitigate this.

▲echoangle 2 hours ago | parent | prev | next [-]

How do you handle file uploads then? Isn’t that handled by the same process writing the uploaded files to disk?

▲trog 4 hours ago | parent | prev | next [-]

But then WordPress stops working :)

▲hparadiz 4 hours ago | parent [-]

They were talking about critical systems :)

▲trog 4 hours ago | parent [-]

Heh, but for better or for worse, a bunch of people have built businesses out of WordPress and its ecosystem. One of them is my aunt, which is why (as a designated family tech support person, though she does have a part time developer) I'm watching this thread closely!

▲bpye 4 hours ago | parent | prev [-]

R/w access to your production database is still a problem, though yes less bad than world read/write.

And also relies on the target being patched against any Linux EoP...

▲stackghost 9 hours ago | parent | prev [-]

I’ve thought about doing this in the past but have no trust in police to see it as a Good Samaritan act

▲asimovDev an hour ago | parent | prev [-]

dozens of thousands if not hundreds of Drupal 7 sites running php 7