Why suPHP Is Insecure for a Joomla Website

Most of the Joomla websites use suPHP, and yet most of the Joomla websites (with vulnerabilities, e.g. those with version less than the current one, or those that have vulnerable extensions installed) are getting hacked. Is that a coincidence? We think not, and we’ll explain why.

What is suPHP anyway?

suPHP is a tool that “claims” to be secure by allowing only owners of files to run them. For example, if a file is owned by user xyz, only user xyz can run this file. suPHP is usually the tool of choice to run PHP scripts on most cPanel installations.

Why do we think that suPHP is not secure?

As we stated earlier, suPHP requires that the user running any php file must be its owner. In a web environment, since Apache must be able to run all the PHP files under the web directory, then this means that Apache must be the owner of these PHP files (if Apache is stripped ownership of any of the PHP files under the web root, then you will see a “500 – Internal Server Error” when Apache wants to run that file). While that doesn’t sound that bad, imagine the following scenario:

  • You have changed the permissions of all your PHP files (recursively) to 444. You did that the right way, by ssh’ing to your machine, and issuing the following command under the root directory of your website:

    find . -type f -exec chmod 0444 {} \;

    You’re now proud because you think that your website is secure.

  • Your website is powered by a hackable version of Joomla or hosts an exploitable extension. A malicious user takes advantage of this exploit and uploads the file writetoindex.php to the images folder (which is the folder du choix for hackers). The writetoindex.php file simply writes some malicious code to your index.php file.

  • You think that since all your PHP files are read only, then if writetoindex.php is run, it will not be able to modify your index.php file. However, you probably forgot one very important thing: the writetoindex.php file is running as Apache, which is also the owner of index.php, which means that all the script needs to do in order to modify your index.php file is to modify its permissions (before attempting to write to it) using the PHP built-in function chmod. Always remember that the owner of the file can change its permissions whenever he feels like it. (You can reproduce this concept on your Windows machine: Create a text file with some content, right click on it, click on Properties and check the Read-only checkbox next to attributes. Now try to edit it and you’ll find out that you’re not able to. Now go back to the properties of the file and uncheck the Read-only attribute and you’ll be able to edit it again!)

We think that you should only use suPHP when you’re 100% sure that your website does not have any vulnerabilities whatsoever, but in this day and age, can anyone be 100% sure of anything?

So now you’re probably wondering, what’s the solution? The solution, in our (ehemmm) humble opinion, is to not use suPHP at all for your Joomla website, and use something else that is more secure, something that will allow Apache to read PHP files even though they are owned by someone else (that someone else might be root), something that will allow you to protect your Joomla PHP files as described here.

Talk to your host about an suPHP alternative, or better yet, contact us and hire us to do that for you and secure your website. We know the ins and out of Joomla, we have secured many websites before, and we don’t charge much!

One Response to “Why suPHP Is Insecure for a Joomla Website”
  1. Pingback by Why You Should Use DSO for Joomla Websites | itoctopus — December 13, 2012 @ 4:30 pm

    […] We have discussed suPHP in a previous post, and explained why it should be avoided on Joomla websites because Apache must have full permissions on all files pertaining to Joomla (including core files), leading to major security issues in case there’s a tiny loophole in the Joomla instance. […]

Leave a comment