SysAdmin Tip - recursive chown can open your system for exploit

03 Jun 2010

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:

  1. The user needs to perform some kind of management on the files; or
  2. 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.

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.
comments powered by Disqus