4 ms·

Yeah, typically, a web server should be setup such that the web servers process runs as say: www-data:www-data, and then the web files should be: joe:www-data a

Yeah, typically, a web server should be setup such that the web servers process runs as say: www-data:www-data, and then the web files should be: joe:www-data and those web files should be 644. In this manner, the web server process can read the files, but the files can neither be written to nor run. This very basic stuff that most of the world seems to ignore completely.

snowwrestler 4y ago
Wordpress typically has write access to itself so it can auto-install updates right away, which is also a good idea for security. But I t’s definitely a tradeoff in that it also increases the potential harm from bugs.
- progval 4y ago
  Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't?
  - codetrotter 4y ago
    > Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? In theory yes. In practice no. I think a big reason that PHP grew popular years ago was that basically all you needed in order to set up a PHP site on a host was FTP access, and in certain cases DB credentials. For example, case in point, for WordPress you only need FTP and DB access. Certainly it was the case for me back in the day, when I started learning to program with PHP. I was still using Windows back then and I knew nothing about Linux or any of the other Unix-likes at the time. All I had was my Windows XP computers with XAMPP, and free hosting which provided me with FTP access. Many free hosts would give you MySQL DB credentials also I think. Cron and things like that would have been beyond my abilities at the time, and beyond what I was given access to by the free hosting companies.
    - sgbeal 4y ago
      >> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? > In theory yes. In practice no. FWIW, after my one and only Wordpress installation was cracked via a vulnerability identical to the one reported in this thread (back in 2010-ish), i did exactly that: made all of the files and dirs read-only to the web user, and made the read/write only during upgrades. Since ditching that site, though, a couple of years later, WP has remained on my blacklist and i've neither touched it nor recommended its use (and actively recommend against it for anyone who asks because of its long, glorious history of being cracked). To this day, WP is still the only server-side software i've ever run which was cracked from the outside.
  - snowwrestler 4y ago
    When I ran self-hosted Wordpress sites I wrote “lock” and “unlock” shell scripts that would alter file/directory permissions so Wordpress could install updates on a fixed schedule. We could also “unlock” and push updates by hand if a patch seemed critical. But, we were running our own Linux servers and had some idea of what we were doing. Many Wordpress site admins don’t. And Wordpress community has decided to err on the side of fast and easy patching over ideal server settings. And honestly it’s hard to fault that decision; the vast majority of attempts on WP sites target known and patched vulnerabilities. Even this article notes “sites running outdated or unpatched versions of these WordPress tools are at risk.” (emphasis mine) Anything that helps people patch faster is probably the right choice for the WP community.
    - deafpolygon 4y ago
      This is what I did when I was admin of a multi-site WordPress install (over 6,000 individual blogs hosted via this one instance). Too many people wanted their own plugins and themes, so I had to come up with a secure method for updating and controlling what gets inside.
- BirAdam 4y ago
  You can actually set WordPress to use SFTP/SSH or ftpsockets for filesystem access, but this will break many popular plugins.
quags 4y ago
This is a valid and secure set up - and should be considered if you are running your own Wordpress site - but not the standard in shared hosting. Most users are isolated from each other and run php under their user name. A reasonable shared host will have some security set up that will protect their clients, and there are plenty to outsource to. This type of exploit is blocked for example using imunify360 with php defense and the waf rules while allowing php to run under the username.

snowwrestler 4y ago

Wordpress typically has write access to itself so it can auto-install updates right away, which is also a good idea for security. But I t’s definitely a tradeoff in that it also increases the potential harm from bugs.

progval 4y ago
Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't?
- codetrotter 4y ago
  > Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? In theory yes. In practice no. I think a big reason that PHP grew popular years ago was that basically all you needed in order to set up a PHP site on a host was FTP access, and in certain cases DB credentials. For example, case in point, for WordPress you only need FTP and DB access. Certainly it was the case for me back in the day, when I started learning to program with PHP. I was still using Windows back then and I knew nothing about Linux or any of the other Unix-likes at the time. All I had was my Windows XP computers with XAMPP, and free hosting which provided me with FTP access. Many free hosts would give you MySQL DB credentials also I think. Cron and things like that would have been beyond my abilities at the time, and beyond what I was given access to by the free hosting companies.
  - sgbeal 4y ago
    >> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? > In theory yes. In practice no. FWIW, after my one and only Wordpress installation was cracked via a vulnerability identical to the one reported in this thread (back in 2010-ish), i did exactly that: made all of the files and dirs read-only to the web user, and made the read/write only during upgrades. Since ditching that site, though, a couple of years later, WP has remained on my blacklist and i've neither touched it nor recommended its use (and actively recommend against it for anyone who asks because of its long, glorious history of being cracked). To this day, WP is still the only server-side software i've ever run which was cracked from the outside.
- snowwrestler 4y ago
  When I ran self-hosted Wordpress sites I wrote “lock” and “unlock” shell scripts that would alter file/directory permissions so Wordpress could install updates on a fixed schedule. We could also “unlock” and push updates by hand if a patch seemed critical. But, we were running our own Linux servers and had some idea of what we were doing. Many Wordpress site admins don’t. And Wordpress community has decided to err on the side of fast and easy patching over ideal server settings. And honestly it’s hard to fault that decision; the vast majority of attempts on WP sites target known and patched vulnerabilities. Even this article notes “sites running outdated or unpatched versions of these WordPress tools are at risk.” (emphasis mine) Anything that helps people patch faster is probably the right choice for the WP community.
  - deafpolygon 4y ago
    This is what I did when I was admin of a multi-site WordPress install (over 6,000 individual blogs hosted via this one instance). Too many people wanted their own plugins and themes, so I had to come up with a secure method for updating and controlling what gets inside.
BirAdam 4y ago
You can actually set WordPress to use SFTP/SSH or ftpsockets for filesystem access, but this will break many popular plugins.

quags 4y ago

This is a valid and secure set up - and should be considered if you are running your own Wordpress site - but not the standard in shared hosting. Most users are isolated from each other and run php under their user name. A reasonable shared host will have some security set up that will protect their clients, and there are plenty to outsource to. This type of exploit is blocked for example using imunify360 with php defense and the waf rules while allowing php to run under the username.