[patio11]

A mitigation for this sort of thing: your Wordpress installations can be owned by someone other than the webserver, with 644/655 permissions. This will prevent folks from uploading arbitrary code (through any of the NUMEROUS plugins/themes with a vulnerability that allows them to do that), and also prevents folks from appending malicious code to known files.

[d2]

You could also "cat /usr/local/wordpress/wp-config.php" and see the plaintext mysql username/password and inject malicious data into the DB, create/drop tables or databases depending on access level.

[d2]

Problem is that then you can't auto install themes, auto update wordpress - and the script causing this vulnerability requires a writable cache directory under the wordpress root.

[patio11]

Yes, turning off the ability to execute arbitrary code on your server through your web browser will, indeed, turn off the ability to execute arbitrary code on your server through your web browser. I think that is a misfeature: if executing arbitrary code on your server could potentially do damage to your business (hint: yes), you should be SSHing into a terminal to do it. That combo will be 500,000x more effective at securing your box than the best efforts of Wordpress, PHP, and the fifteen year-old designer who coded your lightbox plugin after Googling "How to find file name in PHP".

See also my comments last week about the (lack of) wisdom in embedding a ruby shell in a web application.

[dave1010uk]

Turning off the ability to execute arbirary code on your server through your webserver will also stop WordPress from being able to get security updates out to the millions of sites using it.

While I much prefer going through SHH to manage my sites, there are likely 10x as many WP sites run by people who can only FTP. There isn't really an ideal solution in this situation (apart from education) so I think allowing easy updates by having weaker security may be best. Maybe there is a better solution that still works for FTP. If so, file a ticket.

The WordPress Codex is a wiki and it looks like the docs on security could do with some improvements - sign up and help out.

[nbpoole]

You're confusing the issue. This isn't about SSH versus FTP: it's about whether or not the Apache user running your website can also write to the filesystem inside of your document root. The Wordpress update feature is actually able to use FTP as the means of updating the site.

[dave1010uk]

That's true; I was oversimplifying the issue. Most shared hosting web hosts run PHP files with the same user that you FTP with. If WP can't update itself in these cases then the user cannot write files via FTP. If a user connects via SSH then chances are they are comfortable changing directory permissions to do an update.