/scripts/chownpublichtmls problem

[simplybe]

Hi,
I just ran the script /scripts/chownpublichtmls and it broke every site on the server by setting the public_html folders to user:user rather than user:nobody

anyone else experienced this and does anyone know a quick way to fix them all again.

Thanks

[d_t]

You can fix owner this way:

cd /home
for i in *; do echo $i && chown $i:nobody $i/public_html; done

[Spiral]

Here is a quick fix script for that ....

#!/bin/bash
IFS="$"

cd /home

/bin/ls -- /var/cpanel/users | /bin/grep -v "\`\|\.\|\-\|system\|root\|nobody\|mysql\|cpanel" | while read CPUSER; do
   CPHOME=$(/bin/grep "^${CPUSER}:" /etc/passwd | /usr/bin/head -1 | /bin/cut -d':' -f6)
   CPUBLIC="${CPHOME}/public_html"

   if [ -d "${CPUBLIC}" ]; then
      /bin/chown "${CPUSER}:nobody" -- "${CPUBLIC}"
      /bin/chmod 0750 -- "${CPUBLIC}"
   fi
done

If you save that to a file (chmod 700) and drop it in /etc/cron.hourly, it'll run a check every hour and make sure that all your 'public_html' folders still have the correct ownership and permissions. I would only use this in cases where you have problems where your ownerships or main folders keep getting reset by another process which cannot be removed or altered but you can certainly apply the principle to other applications.

[jpetersen]

Here is a quick fix script for that ....

#!/bin/bash
IFS="$"

cd /home

ls /var/cpanel/users | grep -v "root\|nobody\|mysql" | while read CPUSER; do
   CPHOME=$(grep "${CPUSER}:" /etc/passwd | head -1 | cut -d':' -f6)
   CPUBLIC="${CPHOME}/public_html"

   if [ -d ${CPUBLIC} ]; then
      chown ${CPUSER}:nobody ${CPUBLIC}
      chmod 750 ${CPUBLIC} 
   fi
done

If you save that to a file (chmod 700) and drop it in /etc/cron.hourly, it'll run a check every hour and make sure that all your 'public_html' folders still have the correct ownership and permissions.

The race condition in your code allows anyone with access to an account created by cPanel (authenticated or otherwise) to obtain full root privileges.

[Spiral]

The hell it does!

Actually, there is really nothing wrong with the script and you are quite incorrect.

Perhaps you might think that at first glance but stop and think about things for a few
moments and you might realize something you overlooked especially when you take
into context how this script is used and how Linux systems operate.

The code is in fact logically sound and as a side note doesn't make use of any TEMP files
deliberately to avoid any potential possibility of injection prior to script completion and
explicitly prohibits "root" permission settings and even if it didn't, you would only accomplish
rendering the account inaccessible instead of elevating any privileges anywhere.

And then you say "but you could replace the commands" before they execute!

Actually, no you couldn't --- well not easily or without the aide of root in the first place and
I'll explain a bit more specifically some of this further on down below.

However, to your credit a few enhancement revisions could be made such as prefixing the
full path name to all commands to make 100% absolutely sure the correct system commands
are indeed called. However because of the way this script is already configured and that it is
also called as a non-user root cron process with an execution point also outside user access, and
further the way Linux executes path searches by default, it really wouldn't matter much either
way other than just being completely and entirely anal to the nth degree since users would
already have to have both root and detailed knowledge of what is running to make any kind of
exploit against anything as you describe but that by definition, would utterly defeat the
point entirely wouldn't it? The only other way to do this is to change the manner in which
Linux performs command path and force location ahead of system paths in searches but that
would again require root and anyone who is stupid enough to set up their servers that way
has much bigger worries to consider anyway. ROFL

Just for you ...

The following is an enhanced extra extreme paranoid version with log feedback:

#!/bin/bash
IFS="$"

if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

PATH="/bin:/usr/bin"

CPLOG="/var/log/messages"

unset CONFIRM CPUBLIC CPUSER CPHOME 

cd /home

/bin/ls -- /var/cpanel/users | /bin/grep -v "\`\|\-\|\.\|system\|root\|nobody\|mysql\|cpanel" | while read CPUSER; do
   CPHOME=$(/bin/grep -- "^${CPUSER}:" /etc/passwd | /usr/bin/head -1 | /bin/cut -d':' -f6)
   CPUBLIC="${CPHOME}/public_html"

   if [ -d "${CPUBLIC}" ]; then
      CONFIRM="$(echo "${CPUBLIC}" | /bin/cut -d'/' -f3)"
      if [ "${CONFIRM}" = "${CPUSER}" ]; then
         /bin/chown -- "${CPUSER}:nobody" "${CPUBLIC}" > /dev/null 2>&1
         /bin/chmod -- 0750 "${CPUBLIC}" > /dev/null 2>&1
      else
         echo "$(/bin/date) ${CONFIRM} does not match ${CPUSER} in permission update check ..." >> ${CPLOG}
      fi
   else
      echo "$(/bin/date) ${CPUBLIC} folder for ${CPUSER} appears to be missing ..." >> ${CPLOG}
   fi
   unset CONFIRM CPUBLIC CPUSER CPHOME
done

Naturally resetting folder permissions ownerships constantly is a bit overkill but it does have it's application in certain situations ...

In example, I have a client who likes using a 3rd party Cpanel add-on script that hooks in and enhances Cpanel's reseller functions, except that under SuPHP, it routinely blows away ownerships and permissions of all the accounts resetting all files to "root:root" and "600". The script authors encrypted and protected their code rendering a direct fix not practical and the client refuses to change applications so the only working re-course is to leave a process in place to keep permissions and ownerships reset to their original status. The script written for that client is actually nearly identical to the second version above except that it also has a hook in it to trigger automatically upon sites being down because of ownerships being changed by his other program.

[jpetersen]

The hell it does!

Perhaps you might think that at first glance but stop and think about things for a few
moments and you might realize something you overlooked.

Actually, there is really nothing wrong with the script and you are quite incorrect.

The code is in fact logically sound and as a side note doesn't make use of any TEMP files
deliberately to avoid any potential possibility of injection prior to script completion and
explicitly prohibits "root" permission settings and even if it didn't, you would only accomplish
rendering the account inaccessible instead of elevating any privileges anywhere.

And then you say "but you could replace the commands" before they execute!

Actually, no you couldn't --- well not easily or without the aide of root in the first place and
I'll explain a bit more specifically some of this further on down below.

However, to your credit a few enhancement revisions could be made such as prefixing the
full path name to all commands to make 100% absolutely sure the correct system commands
are indeed called. However because of the way this script is already configured and that it is
also called as a non-user root cron process with an execution point also outside user access, and
further the way Linux executes path searches by default, it really wouldn't matter much either
way other than just being completely and entirely anal to the nth degree since users would
already have to have both root and detailed knowledge of what is running to make any kind of
exploit against anything as you describe but that by definition, would utterly defeat the
point entirely wouldn't it? The only other way to do this is to change the manner in which
Linux performs command path and force location ahead of system paths in searches but that
would again require root and anyone who is stupid enough to set up their servers that way
has much bigger worries to consider anyway. ROFL

Just for you ...

The following is an enhanced extra extreme paranoid version with log feedback:

#!/bin/bash
IFS="$"

if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

PATH="/bin:/usr/bin"

CPLOG="/var/log/messages"

cd /home

/bin/ls /var/cpanel/users | /bin/grep -v "root\|nobody\|mysql" | while read CPUSER; do
   CPHOME=$(/bin/grep "${CPUSER}:" /etc/passwd | /usr/bin/head -1 | /bin/cut -d':' -f6)
   CPUBLIC="${CPHOME}/public_html"

   if [ -d ${CPUBLIC} ]; then
      CONFIRM="$(echo ${CPUBLIC} | /bin/cut -d'/' -f3)"
      if [ ${CONFIRM} = ${CPUSER} ]; then
         /bin/chown ${CPUSER}:nobody ${CPUBLIC} > /dev/null 2>&1
         /bin/chmod 0750 ${CPUBLIC} > /dev/null 2>&1
      else
         echo "$(/bin/date) ${CONFIRM} does not match ${CPUSER} in permission update check ..." >> ${CPLOG}
      fi
   else
      echo "$(/bin/date) ${CPUBLIC} folder for ${CPUSER} appears to be missing ..." >> ${CPLOG}
   fi
   unset CONFIRM CPUBLIC CPUSER CPHOME
done

So does this.

[Spiral]

So does this.

You think you have something, but you do not! Private message me and we can discuss this in more detail as well as why what you think won't work in any practical application in this instance! And for the record, I do actually know what you are thinking but you are incorrect and that won't work beyond theoretical application. If this script had been anything other than it was or had been designed for user use, then yes certain additional considerations would need to be made but it isn't of much relevance in this particular instance.

Anyway, like I said before, stop and think about it for a few moments .

[jpetersen]

You think you have something, but you do not! Private message me and we can discuss this in more detail as well as why what you think won't work in any practical application in this instance! And for the record, I do actually know what you are thinking but you are incorrect and that won't work beyond theoretical application. If this script had been anything other than it was or had been designed for user use, then yes certain additional considerations would need to be made but it isn't of much relevance in this particular instance.

Anyway, like I said before, stop and think about it for a few moments .

Also, the race condition isn't the only bug that allows anyone with access to an account created by cPanel (authenticated or otherwise) to obtain full root privileges.

[tsiedsma]

Also, the race condition isn't the only bug that allows anyone with access to an account created by cPanel (authenticated or otherwise) to obtain full root privileges.

You know what is helpful to everyone? If you actually outlined the problem and proposed a solution.

[cPanelDon]

To everyone in this thread,
Please refrain from personal insults and please remain peaceful, providing constructive criticism in a way that is respectful to your fellow forum visitors. Thank you.

[cpanelkenneth]

You know what is helpful to everyone? If you actually outlined the problem and proposed a solution.

Spiral presents himself as a renowned security professional. He should know, based upon the information jpetersen provided, what the flaws are with his script.

Here are two guidelines for readers of this thread:

1. Do not use the script Spiral provided

2. Never, as root, attempt to chown a file that is under a user's control

If you desire to improve your ability to write programs or scripts that are secure from the get-go a good starter resource is Secure Programming for Linux and Unix HOWTO