Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30014
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain rowe-clan.net from 64.202.165.33 cause and error)
Message-ID: <465F3A9C.6000300@rowe-clan.net>
Date: Thu, 31 May 2007 16:14:04 -0500
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To:  ceo@l-i-e.com
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <465F31C8.8030208@rowe-clan.net> <39584.216.230.84.67.1180644880.squirrel@www.l-i-e.com>
In-Reply-To: <39584.216.230.84.67.1180644880.squirrel@www.l-i-e.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Toggling enable_dl API off for runtime?
From: wrowe@rowe-clan.net ("William A. Rowe, Jr.")

Richard Lynch wrote:
> On Thu, May 31, 2007 3:36 pm, William A. Rowe, Jr. wrote:
>> In httpd server (and most) there is a startup phase, when we generally
>> trust what the admin has done, and a runtime phase.  There are obvious
>> exploits if untrusted scripts can run arbitrary dlload's after
>> startup.
> 
> Call me silly, but if you've got untrusted scripts running, dl or no
> dl, you are in a boat-load of trouble...

We don't disagree :)  But it seems many hosters are happy to do this
for arbitrary people with a very low identity threshold.

>> enable_dl in php.ini will obviously override this, but to start up and
>> load dynamic extensions, it's initially required to be on.
>>
>> Is there any sense in having php4apache2 (and other SAPI's) permitted
>> to run the entire startup phase of php prior to turning enable_dl back
>> off for the runtime phase of the server?
> 
> I still haven't figured out why dl() needs to go away at all, frankly.
> 
> Why not default if off and add yet another php.ini flag, or add a
> special php.ini flag which does the exact same thing as putting dl on
> the list of banned functions.

As Rasmus pointed out, there's no need for two flags.

> I'm not seeing the big win of killing dl...

Nor I - you point out the right solution in your first paragraph.

But given that people seem to do this, dl certainly allows a much more
fine-grained abuse of httpd, IIS, etc in-process than the php language
itself.  /shrug

Mostly responding to the dire sounding "Apache httpd vulenrabilities"
bugtraq message id <Pine.GSO.4.64.0705291959110.23746@rose.man.poznan.pl>
which consisted of one "real bug" comingled with many silly claims.  Thus
the one year lack of response by httpd - trawling through his original
pile of poop for the one diamond in his claims was more cycles than any
of the security team could stand.

For my future reference, running untrusted php scripts for end users is
not a design consideration?  Cohosted php scripts running on the same
server instances / processes is not "supported"?

My point is that once the process is poisoned by one vhost's php script,
that same process is used again for another vhost.  Obviously there are
other posix_* api calls that might also be a concern, but unless the admin
sets 'MaxRequestsPerChild 1' - the subsequent request is running in the
environment of the prior request (and let's not even start with the worker /
threaded side effects ;-)

An example php.ini file that is significantly immune to these side effects
would seem to be a good idea.  Either that, or a "DON'T COHOST UNTRUSTED
SCRIPTS" disclaimer :)

Bill