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 (at) bit (dot) nl [email concealed]> modified for cpanel by

nick (at) darkorb (dot) net [email concealed]"

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 (at) asquad (dot) com [email concealed]

http://www.A-Squad.Com

[ reply ]