A scenario system admins often encounter on shared hosting servers is the permission and ownership issue caused by using mod_php (otherwise known is PHP DSO). Files and directories created by mod_php will be owned by the user that Apache runs as, usually nobody or www-data. This presents a problem in at least two scenarios:
- The user needs to perform some kind of management on the files; or
- The sysadmin wants to convert to a more secure method of serving PHP content, usually mod_suphp where such ownership mis-match will cause 500 Internal Server errors.
One method often espoused when discussing how to address the ownership issue is to merely execute a recursive chown of the user’s home directory, like such:
root@localhost # chown -R user:user /home/user
The recursive chown can open your system to exploitation. Let me demonstrate with a simple example.
Note: I strongly urge you to not perform this test on a production system. Use a throw away system, such as a VPS test system.
Note: the following will not work if the home directory for the user, or /etc is on a separate file system. Hard links may not cross device boundaries.
[root@squash ~]# ls -l /etc/shadow -rw------- 1 root root 0 Jun 3 07:30 /etc/shadow [whoanel@squash ~]$ ln /etc/shadow public_html/favorite_book_list.txt [whoanel@squash ~]$ ls -l public_html/favorite_book_list.txt -rw------- 2 root root 905995 May 14 09:49 public_html/favorite_book_list.txt [root@squash ~]# chown -R whoanel:whoanel /home/whoanel [root@squash ~]# ls -l /etc/shadow -rw-r--r-- 2 homer homer 0 Jun 3 07:35 /etc/shadow
The point to derive from the above is that the recursive chown will grant ownership of hard-linked files to the malicious user.
As noted before the example, the hard link vector will only work on files existing on the same partition/file system as the malicious account. Rather than targeting /etc/shadow such a user may try to link to other sensitive files, such as .my.cnf, wp-config.php and the like.
For this attack to properly work, the malicious user must accompany it with a social engineering vector. One can imagine a support request like:
“Hey, I'm trying to manage some files in my account but I keep getting errors. Could you help me?”
By sprinkling files throughout the directory via mod_php (thus increasing the cost of examining each file before changing ownership) the malicious user can mask his intent.
“Can’t I simply block the ability to create hard links?” If the user can run code at all on the system, then he can create a hard link.
The point I want to leave you with is this:
Don't blindly perform a recursive chown. Examine and perform a specific chown.