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

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

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..

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

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

Benevolent worms.

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

Heheh that's cute.

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

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

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

Paying a ransomware attack tomorrow is very much better, than not having critical medical data for the emergency right now. Of course not having a public facing medical database based on PHP, would be even better, but that might not be a decision that they are able to make right now.

Either way you're having a day or more of downtime. No reason to assume today is worse than tomorrow.

I think this is an instance of the trolley problem. So, don't expect to find a correct answer.

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

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

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?

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.

But then WordPress stops working :)

They were talking about critical systems :)

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!

Does she actually need WordPress/Plugin features or is it mostly about editing the site herself? would something like Publii work too? Static sites dont have CVEs and you still get a nice WYSIWYG editor so she can update the site on her own.

Did this with my parents websites and they are quite happy and I get basically no support calls (and can read threads like this one out of interest only, thankfully)

Sadly yes, it's a whole stack (built for her by a vaguely technical cofounder who has since left the business) with a bunch of business-critical plugins, including Woocommerce for handling credit card payments via Stripe and another plugin handling bookings. It's amazing for what it is but it is a bit of a nightmare to keep going.

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...

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.

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

You could write them into a database instead. Or you make an exception for them.

>You could write them into a database instead.

"How to make your site cost unlimited money and have terrible performance". People did this in the Web 1.0 days on occasion and it leads to all kinds of problems for any site with any kind of traffic.

>Or you make an exception for them.

Useless. All you need to do at that point is chain a priv-esc to your existing exploit and you get root.

This is probably possible, there are github repos of extensions you can build for almost every distro and php version. You could probably pre-build most and then just do a background php extension load and restart.

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

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.

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.

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