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 <[EMAIL PROTECTED]> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
