Hacker News Reader

Comment by kijin | Hacker News Reader

Aaaaand of course there are downsides to every convenient feature.

Ability to install plugins directly from the admin interface? Instantly enable them without restarting anything? This is only possible because your plugins directory and everything in it is writable by the web server. In other words, any plugin can mess with any other plugin, or even WordPress itself. The only reason this doesn't happen is because you have yet to come across a malicious plugin.

WordPress plugins can do anything and everything. They are very powerful. Therefore, they should be treated with the same level of caution that any powerful yet relatively unrestrained program deserves. Like ActiveX controls on IE6 (shudder). You don't simply search n' download them for a test drive, unless you really really trust the competence and moral integrity of the author and the repository.

View on HN

> Therefore, they should be treated with the same level of caution that any powerful yet relatively unrestrained program deserves.

A friend of mine's mother routinely compromises his vps simply by installing themes which include the popular TimThumb (https://code.google.com/p/timthumb/) plugin. Through the plugin, it's easy for an attacker to install web shells etc.

This is true of many plugin systems, and RubyGems for example is not immune from this. The difference between installing a new gem however, is that as a software engineer or developer it's your job to have confidence in the security of the gem. With a Wordpress plugin, any user of Wordpress can easily install it, and sometimes it's the theme which includes the plugin.

The old Tim Thumb is vulnerable. The writer of tim thumb fixed that security hole though after the issue from what I read.

...so one of the basic security things one must do on a webserver is separating the vhost unix accounts (to avoid compromised installs overtaking other vhosts), as well as separating the web server virtual account from the FTP account.

Wordpress then can update itself using your FTP credentials, but a malicious or hacked plugin can not compromise the site.

That still leaves the wp-content directory and everything in it, including other plugins, writable by the web server. A malicious or compromised plugin can then check whether some of the highly popular plugins are installed, and modify their files to compromise the whole site. You don't need access to WordPress's core files to inflict a huge amount of damage.

Some directories do need to be writable for caching and uploading purposes, but those are just data, and data is usually inert. It's dangerous to leave any executable file (*.php) writable by the web server.

>That still leaves the wp-content directory and everything in it, including other plugins, writable by the web server.

You don't have to have the wp-content directory writable by the web server. I certainly don't on the WordPress installs that I maintain. I also do not have FTP open and listening. Users can SSH/SFTP files up if they wish, but I don't let the web server write into the Wordpress area for specifically that reason.

It does not, read exactly what I've written above - there are three users in total: your ssh login-account, the (user-unique) PHP account (suphp or similar solution used for this) and the user-unique FTP account.

So, if you set up the ACLs and permission bits correctly, the webserver has no write rights, only you and the FTP user have.

Reply on news.ycombinator.com