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.
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?
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.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?
enable_dl only affects the userspace dl() function. That can only be
called at the runtime phase, as you call it. So what you are proposing
doesn't make much sense.
-Rasmus
Rasmus Lerdorf wrote:
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.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?enable_dl only affects the userspace
dl()function. That can only be
called at the runtime phase, as you call it. So what you are proposing
doesn't make much sense.
Thank you for clarifying, Rasmus.
Since userspace dl() can pollute future requests on the same prefork worker,
or pollute other workers running on the threaded/worker style MPM, is there
any thought to disabling this by default in at least one of the flavors
of proposed php.ini solutions that are provided with the distribution?
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...
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.
I'm not seeing the big win of killing dl...
--
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?
Richard Lynch 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
William A. Rowe, Jr. wrote:
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 :)
Disabling dl() is a rather well-known ISP configuration. And it isn't
allowed at all in any threaded sapis, so that part isn't an issue. I
guess you are asking us to provide an example .ini file for hosting
companies. The sticky point here is that I think most of us would
suggest using a fastcgi or a completely vm'ed setup for any sort of
secure hosting. And in both those cases dl() wouldn't actually be a
problem.
-Rasmus
Rasmus Lerdorf wrote:
William A. Rowe, Jr. wrote:
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 :)Disabling
dl()is a rather well-known ISP configuration. And it isn't
allowed at all in any threaded sapis, so that part isn't an issue. I
guess you are asking us to provide an example .ini file for hosting
companies. The sticky point here is that I think most of us would
suggest using a fastcgi or a completely vm'ed setup for any sort of
secure hosting. And in both those casesdl()wouldn't actually be a
problem.
I concur w.r.t. cgi, that's the gist of the response to bugtraq I'm drafting.
Richard Lynch 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. /shrugMostly 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 :)
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?