SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Generic)  >   cPanel Vendors:   cPanel, Inc.
cPanel suEXEC Flaw May Let Remote Authenticated Users Execute Abitrary Code
SecurityTracker Alert ID:  1010411
SecurityTracker URL:  http://securitytracker.com/id/1010411
CVE Reference:   CVE-2004-0529   (Links to External Site)
Date:  Jun 7 2004
Impact:   Execution of arbitrary code via network, User access via network
Exploit Included:  Yes  
Version(s): 9.3.0-EDGE_95 and prior versions
Description:   A vulnerability was reported in cPanel in suEXEC. A remote user may be able to execute arbitrary code with the privileges of another user.

Rob Brown reported that there is a flaw in a cPanel patch to the Apache suEXEC when configured for mod_php that can be exploited in conjunction with some cPanel perl scripts. A remote authenticated user may be able to execute arbitrary code with an arbitrary user id (uid) that is 100 or greater.

Systems using Apache 1.3.31 compiled without mod_phpsuexec are affected.

The suEXEC compiled with cPanel reportedly allows a remote authenticated user to execute "shared" scripts as an arbitrary user by invoking the web server (with "nobody" privileges) to execute the target script. Only target scripts owned by the 'root' user and 'wheel' group are affected, the report said.

It is also reported that some perl scripts owned by user 'root' and group 'wheel' are unsafe (untainted) and can be compromised, including '/usr/local/cpanel/bin/proftpdvhosts'.

The report indicates that you can scan for the affected perl scripts with the following command:

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

A demonstration test script is available at:

http://64.240.171.106/cpanel.php

The vendor has been notified. The bug report is available at:

http://bugzilla.cpanel.net/show_bug.cgi?id=668

Impact:   A remote authenticated user can execute arbitrary code with an arbitrary uid (of 100 or greater).
Solution:   No solution was available at the time of this entry.

The author of the report has provided the following solution recommendations:

"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."

Vendor URL:  www.cpanel.net/ (Links to External Site)
Cause:   Access control error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.


 Source Message Contents

Subject:  cPanel mod_php suEXEC Taint Vulnerability




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 

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC