Toggling enable_dl API off for runtime?

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

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