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@xxxxxx> modified for cpanel by
nick@xxxxxxxxxxx"
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@xxxxxxxxxx
http://www.A-Squad.Com