On Thu, May 31, 2007 4:14 pm, William A. Rowe, Jr. wrote: > 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 :)
Maybe I'm being naive, but why can't a script un-dl() whatever got dl-ed when it ends? If you can nuke the MySQL connection and all the other resources, and you can reset state to zero, why does a dl() hang around? Just unlink it or whatever. Does not the OS provide the low-level call to do this? I thought that was part of the feature set of DLLs/.so in the first place, no? Sure, if my dl() went and peeked and poked at RAM and was actively hacking at things, that's a different kettle of fish... But I can do (almost) equally nasty things just with PHP anyway, really. Seems like two issues have been crammed together: dl() changes the environment for next script dl() can be used to do Evil Seems like if you fix the first one, you'd have no real strong reason to try to fix the second... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
