The following comments apply to WordPress v 3.1.3 and may not apply to earlier versions, with which I have no familiarity.
WordPress has an interesting idea for doing upgrades and downloading plugins. It took some getting used to until I learned to embrace it. I needed to understand the security considerations. Now I have a much better handle on it and feel comfortable with it.
First thing after installing WordPress, Murphy’s law you know, I was presented with an important security upgrade the very next day. I did the upgrade the hard way, doing all the file manipulation by hand. Copying files here and there, etc. I run the web server with a different user than the owner of the HTML documents to make things more secure. So I naively figured there was no way WordPress’s offer of automatically updating my installation would be possible in my case. After all all it could do was to run with the permissions of the web server, which as I say doesn’t have permissions to write to the relevant parts of the filesystem, right?
Then I learned that my colleagues on the Newton Robotics Team were managing to do it under the same conditions, so it piqued my curiosity. The next plugin I wished to install, WP-Syntax, offered me the same possibility of automatically installing it from the WordPress Admin GUI. It suggested that all I needed was to enter FTP credentials or use FTP/SSL. It did not explain how those credentials were going to be used, and I feared that they would be shared with another site. Let’s think about this (this is how an IT person thinks). There are two main possibilties. 1) The FTP client is initiated from an external site, probably where the repository where the plugin is housed, e.g., wordpress.org. It was my gut feeling that was the case. 2) that the FTP client is on my local server where I run WordPress. But, huh, what’s the point of that?
Turns out that 2) is what’s happening. But then what is the point and how does it work? By reverse engineering and reasoning, it must work as follows. WordPress must download the plugin from the distribution site, perhaps through HTTP or FTP. Perhaps it uses the FTP proxy feature where an intermediate can have an FTP connection to twp FTP servers and transfer files between them. To expand it and put it into the local WordPress plugins directory, where the web server doesn’t have permissions to write, it definitely has to use FTP, but you gave it the credentials of the account that does have permissions to write to the plugins directory! Clever, huh? Of course this presupposes something. Maybe if I read the WordPress requirements I would see that running an FTP server is strongly recommended. But I didn’t so this is another lesson learned through the school of hard knocks! You see, Ubuntu server and I think most linux distributions do not even bother to give you an FTP server. Without a local FTP server WordPress cannot pull off its trick. I’m not sure why they cannot use sftp, which is pretty universal these days. In Ubuntu, you have the FTP client, but not the server.
I tried to run ftpd on my server to see what I would get. It was missing and several packages which provide it were mentioned. I chose inetutils-ftpd: sudo apt-get install inetutils-ftpd. I quickly learn that it relies on inetd, which I see I am not even running. But it also has the option to run as a daemon: ftpd -D, which I chose to do (it won’t start after reboot without more jiggering, but I can start it by hand as I don’t need it often).
But how do I test my new FTP server? Will it really work when WordPress tries to use it?
Feb 2012 Update
I am now comfortable with directing WordPress to do my upgrade. I got tired of it bugging me about the 3.3.1 release so I relented and upgraded to it. I learned how to backup my database first, which is when I saw it was dominated by all the spam and scams I have been receiving. So I went back to the dashboard, got rid of 600 spam comments and re-ran the database mysqldump. The database dump file reduced in size from 10 MB to 3 MB! So it was 70% spam. Great people out there, huh? But I digress. I temporarily enabled my FTP daemon as described above and all went fine.
Then I enabled simple captcha challenge for POSTers. For now simple math seems to be flummoxing the auto-scam submitters! Next day my instance died. No idea why…
One reply on “Security Considerations for WordPress Plugins and Upgrades”
I believe that WordPress utilizes the FTP that is built into PHP. This would most likely be the case so that on the post of the web form it inserts the values into the FTP variables and downloads the respective file through FTP so that the credentials would not be shared with outside sources, they would only be shared internally.