SEVERITY: 
 
High, Arbitrary Execution as Arbitrary User 
 
PROBLEM DESCRIPTION: 
 
Flaws in how Apache's suexec binary has been patched 
by cPanel when configured for mod_php, in conjuction 
with cPanel's creation of some perl scripts that are 
not taint clean, allow for any user to execute 
arbitrary code as any other user with uid above 
UID_MIN ( uid >= 100). 
 
IMPACT: 
 
Unfortunately, cPanel comes with mod_php installed by 
default, so all systems are vulnerable right out of 
the box.  Any local user can comprimise the whole 
system. 
 
SYSTEMS AFFECTED: 
 
All systems where Apache has been compiled WITHOUT 
mod_phpsuexec, (most systems using cPanel software), 
are vulnerable.  Those configurations that compiled 
Apache WITH mod_phpsuexec are NOT VULNERABLE. 
 
Apache versions 1.3.31 and below are VULNERABLE. 
 
All cPanel versions (STABLE, RELEASE, CURRENT, and 
EDGE) up through and including 9.3.0-EDGE_95 are 
VULNERABLE. 
 
RedHat 7.3, 8.0, 9, and Enterprise Linux, Fedora, and 
FreeBSD OS have been verified vulnerable.  All others 
are probably vulnerable too. 
   
TECHNICAL DETAILS: 
 
This vulnerability can be exploited through a 
combination of flaws: 
 
1) 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 probably isn't a good idea when 
different users are hosted on the same machine and 
where one user does not necessarily need to trust the 
other user.  But I believe this flaw is just how 
mod_php works and is the intended behaviour.  This 
probably cannot be fixed.  So think of it more as a 
feature.  Too bad this is the default configuration 
that cPanel uses. 
 
2) The suexec that is compiled with cPanel permits 
this nobody user to execute common or "shared" 
scripts as any arbitrary user.  This is not the 
behavior of suexec that comes stock with Apache, but 
cPanel intentionally applied a patch to 
src/support/suexec.c in order to accomplish this 
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. 
 
I'm not sure where the patch originally came from or 
who to notify with the fix that plugs the hole, but 
the comments say: "patch added by Sabri Berisha 
<sabri@bit.nl> modified for cpanel by 
nick@darkorb.net" 
 
3) There exist some perl scripts owned by root.wheel 
which have not been properly taint cleaned.  This is 
bad because untainted scripts can be exploited to do 
anything.  For example, here is an untainted perl 
script owned by root.wheel which can easily be 
comprimised: 
 
-rwxr-xr-x  1 root  wheel  1385 Feb 22  2003 
/usr/local/cpanel/bin/proftpdvhosts 
 
I reported another one in July 2003, but instead of 
fixing the actual problem, cPanel just nuked that one 
file, namely: 
 
-rwxr-xr-x  1 root  wheel    25 Jul 16  2003 
/usr/local/cpanel/cgi-sys/addalink.cgi 
 
4) Here is a quick way to scan for all the other 
root.wheel untainted perl scripts: 
 
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 
 
If this does not give any output, then the system is 
secure against this vulnerability.  Fortunately, 
unprivileged users will not be able to execute this 
scan test. 
 
PROOF OF CONCEPT: 
 
This tester php script 
http://64.240.171.106/cpanel.php can be used to test 
a configuration for this vulnerability (as well as a 
few other vulnerabilities).  It is written in php in 
order to take advantage of the "running as a common 
user" issue (#1 above).  It then runs a perl script 
as this common user to exploit the "untainted perl" 
issue (#3 above).  Since suexec has been patched to 
allow execution of "shared" programs (#2 above), the 
vulnerability is exploited.  See 
http://www.a-squad.com/audit/ for more details on 
this tester script. 
 
SOLUTION (WORK AROUNDS): 
 
The vendor is aware of the issue but, unfortunately, 
has not posted any solution as of yet.  Each has its 
own drawbacks, but any or all of the following will 
secure the system and eliminate this vulnerability:   
 
1) The best solution (which avoids several other 
problems as well) may be to switch from mod_php to 
mod_phpsuexec.  Recompile Apache with mod_phpsuexec 
using /scripts/easyapache option 2.  But beware, 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 
may be a difficult migration for some host providers.  
DO THIS AT YOUR OWN RISK! 
 
2) Remove the patch 
/home/cpapachebuild/buildapache/suexec.patch after 
starting /scripts/easyapache but before selecting 
option 1.  This will secure your server but will 
cause some functionality to be lost that depends on 
"shared" scripts, such as going to site.com/cpanel in 
the browser.  Probably not the best work around, but 
at least you can keep mod_php. 
 
But maybe it would be more appropriate to actually 
fix the suexec.patch to scan parent directories for 
insecure environments before permitting execution. 
 
3) If you cannot afford to break currently 
functioning PHP scripts for some users or are worried 
about switching from mod_php to mod_phpsuexec or you 
are not comfortable messing with the suexec.patch, 
then you can just taint clean the root.wheel perl 
scripts yourself.  It's basically just adding the 
"-T" to the shebang and then getting it to execute 
cleanly.  Here is a simple patch that fixes the 
specific one mentioned above: 
 
---- snip ---- 
--- /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"); 
 } 
---- snap ---- 
 
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.  It is the vendor's responsibility to 
provide taint clean scripts or else compile them to 
binary. 
 
4) 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 
 
Then you don't really have to fix any code, just make 
sure it is group owned as root. Unfortunately, if it 
really does need to run as a shared script or must be 
owned by root.wheel for some other reason, then this 
solution will not work.  I'm not familiar with what 
all these scripts are used for or what side-effects 
drawbacks this may cause. 
 
So basically to be safe, all root.wheel owned perl 
executables need to be taint clean.  If you can't 
make it taint clean, then delete it, or don't let it 
be root.wheel owned. 
 
REFERENCES: 
 
CVE IDENTIFIER: CVE-2004-0529 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0529 
 
cPanel's Internal Ticket Request: 
#17703 (no public URL) 
 
cPanel's Bugzilla Database Entry 
http://bugzilla.cpanel.net/show_bug.cgi?id=668 
 
A-Squad.Com's Free Security Audit 
http://www.a-squad.com/audit/ 
 
Another related issue (some have confused these two 
issues with each other because one pertains to 
mod_phpsuexec, and the other pertains to 
/usr/local/apache/bin/suexec with mod_php, but they 
are separate issues): 
http://cve.mitre.org/cgi-bin/cvename.cgi?CVE-2004-0490 
 
 
Let me know if you need any more details. 
 
Rob Brown rob@asquad.com 
http://www.A-Squad.Com