Wouldn’t it be excellent if your installation of WordPress could patch itself with the latest security update? Well, I’ve thought of a way to do just that.
I was just checking in on the Lussumo blog (the people who develop my favorite open source forum software) and I came across the post “Server Hacked“. Apparently their server was hacked through an exploit in DokuWiki.
Yet another instance of an outdated web application causing a critical security hole. As soon as I read this, a flood of old thoughts came rushing back surrounding the pains of installing and upgrading web applications. However, this also inspired some exciting new thoughts.
Until today I thought installation was the biggest pain with web applications. I was wrong. Since you only install once and upgrade an indefinite number of times, upgrading is by far the biggest pain. And upgrading is actually more work. You need to backup your files and database and then perform the upgrade, which usually involves as many steps as an installation. WordPress is quite easy to upgrade, but I rarely upgrade this installation simply because I can’t be bothered every time a security upgrade is released. Automatic updates are the solution. A service whereby the development team can push out critical updates to those subscribed. Unfortunately there is at least one tough challenge impeding this service from being realized.
Unlike a desktop application, a web application does not traditionally have access to update itself. There is a rather long and complicated reason for this that I have explained later, if you care to read it. It has long been considered a security faux pas to give a web application access to modify all of it’s own files. Vulnerabilities in the web application could be exploited giving a hacker access to modify the application to do malicious things like browse directories on the server and send SPAM. Unfortunately, this is happening anyway. Web applications are left unattended, become out-of-date, and vulnerabilities that have long been fixed are exploited.
I have come up with of a couple of possible solutions:
- Give the web application access to update itself
- I believe that it’s an acceptable security trade-off to give the web application access to it’s files and gain the ability to push critical updates as soon as they are ready. Although it’s traditionally a faux pas, I strongly believe we have a better chance maintaining security with this approach.
- Schedule a script to run updates
- A cron job (or scheduled task) can run as the user who owns the web application files, so permissions are not a problem here. However, this will require some additional installation steps that the user may not be familiar with.
I am partial to giving the web application access to update itself because it does not require any extra installation instructions. The typical “chmod 777 config.inc.php” step can simply be replaced with “chmod -R 777 wordpress/.” A whole series of additional installation steps need to be followed in order to setup the scheduled script. I believe most users would just skip this procedure. However, both options could be implemented so that savvy users can choose the scheduled script option if they would like to preserve file permission security.
Why can’t a web application write files by default?
The Apache web server runs as a single user, e.g. “www.” The web application files on the server are owned by a user, e.g. “bradt” and a group, e.g. “www.” Usually the default permissions on a file allow the user full access and the group read access. Since a web application runs under Apache as “www,” it only has read access to a file with default permissions. Historically you could use suExec to fork off CGI processes as any user, not just the user Apache is running as. So your Perl or PHP script could run as a CGI process as user “bradt” and would have full access to all the files owned by user “bradt.”
These days we rarely use CGI. Instead we run Perl and PHP as Apache modules, mod_perl and mod_php. Modules do not fork off additional processes but create threads within the Apache process. So with modules, it is no longer possible to manage permissions at the process level. We are forced to change file permissions to give the web server and inherently the web application, full access to files. This is precisely why web applications have installation instructions like “Set permissions on the ‘albums’ and ‘include’ folders in your Coppermine directory.” (Coppermine Installation Documentation)