Comment by hparadiz
20 hours ago
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.
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.
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!
2 replies →
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...