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