发布时间 :2004-08-06 00:00:00
修订时间 :2016-10-17 22:45:58

[原文]The modified suexec program in cPanel, when configured for mod_php and compiled for Apache 1.3.31 and earlier without mod_phpsuexec, allows local users to execute untrusted shared scripts and gain privileges, as demonstrated using untainted scripts such as (1) proftpdvhosts or (2) addalink.cgi, a different vulnerability than CVE-2004-0490.


        cPanel中改进的suexec程序存在漏洞。在没有mod_phpsuexec配置mod_php和编译Apache 1.3.31及其早期版本时本地用户可以执行共享的不受信任脚本和提升特权,正如使用1) proftpdvhosts或者(2) addalink.cgi的未污染脚本,该漏洞不同于CVE-2004-0490。

- CVSS (基础分值)

CVSS分值: 7.2 [严重(HIGH)]
机密性影响: COMPLETE [完全的信息泄露导致所有系统文件暴露]
完整性影响: COMPLETE [系统完整性可被完全破坏]
可用性影响: COMPLETE [可能导致系统完全宕机]
攻击复杂度: LOW [漏洞利用没有访问限制 ]
攻击向量: LOCAL [漏洞利用需要具有物理访问权限或本地帐户]
身份认证: NONE [漏洞利用无需身份认证]

- CPE (受影响的平台与产品)


- OVAL (用于检测的技术细节)


- 官方数据库链接
(官方数据源) MITRE
(官方数据源) NVD
(官方数据源) CNNVD

- 其它链接及资源
(UNKNOWN)  BUGTRAQ  20040605 cPanel mod_php suEXEC Taint Vulnerability
(UNKNOWN)  XF  cpanel-suexec-command-execute(16347)

- 漏洞信息

高危 未知
2004-08-06 00:00:00 2005-10-28 00:00:00
        cPanel中改进的suexec程序存在漏洞。在没有mod_phpsuexec配置mod_php和编译Apache 1.3.31及其早期版本时本地用户可以执行共享的不受信任脚本和提升特权,正如使用1) proftpdvhosts或者(2) addalink.cgi的未污染脚本,该漏洞不同于CVE-2004-0490。

- 公告与补丁


- 漏洞信息 (F33493)

cpanelPHP.txt (PacketStormID:F33493)
2004-06-08 00:00:00
Rob Brown  

Flaws in how Apache's suexec binary has been patched by cPanel when configured for mod_php, in conjunction 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 a uid above UID_MIN.

High, Arbitrary Execution as Arbitrary User 
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). 
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 
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 
RedHat 7.3, 8.0, 9, and Enterprise Linux, Fedora, and 
FreeBSD OS have been verified vulnerable.  All others 
are probably vulnerable too. 
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 
<> modified for cpanel by" 
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 
-rwxr-xr-x  1 root  wheel  1385 Feb 22  2003 
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 
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. 
This tester php script 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 for more details on 
this tester script. 
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.  
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 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 -T 
+%ENV = (PATH => "/usr/bin:/bin/:/sbin:/usr/sbin"); 
---- 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 
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. 
cPanel's Internal Ticket Request: 
#17703 (no public URL) 
cPanel's Bugzilla Database Entry 
A-Squad.Com's Free Security 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): 
Let me know if you need any more details. 
Rob Brown 

- 漏洞信息

cPanel suEXEC Privilege Escalation

- 漏洞描述

Unknown or Incomplete

- 时间线

2004-06-09 Unknow
Unknow Unknow

- 解决方案

Unknown or Incomplete

- 相关参考

- 漏洞作者

Unknown or Incomplete