Hi,
First of all I admit I'm no PHP security expert or PHP internals expert
or anything, so please don't flame me if I say something stupid.
Wouldn't simply adding a flag to allow url's (which includes all '*://'
streams), in functions that opens streams be enough? For example:
fopen($file, 'r') and fopen($url, 'ru') and fopen('php://output', 'ru').
To my opinion, using '*://' streams is an advanced feature. Developers
who are using that, should be able to make sure no urls are opened.
Again, just an idea.
Last, I'm a software developer at a shared hosting company. To my
opinion, making sure that users don't touch other people's files, does
not belong in the PHP layer. With other apache modules you can do nasty
thing as well. We (not me) have written a kernel patch to allow
switching of the current processes (much like sudo) and a matching
apache module. Since the privileges only allow the user or group to
access the file, linux does the rest. An other solution is to start PHP
as cgi under the correct user, but other things will never be really save.
Best regards,
Arnold
Greg Beaver wrote:
> Stanislav Malyshev wrote:
>
>> SE>>And If I am not completely mistaken here unlike php://filter a
>> SE>>userstream will not give the THIS_IS_AN_INCLUDE_FLAG down to a stream
>> SE>>itself opens.
>>
>> I think I see what you mean now - i.e. that the user implementation might
>> be tricked into opening URL for include even though direct opening URL for
>> include is not allowed, and since it would do e.g. fopen, it may work
>> around the allow_url_include.
>>
>> I would say in most cases prohibiting anything but plain file wrapper for
>> include might be OK, however I know about a number of instances of
>> legitimate wrappers used for include - e.g. archive files like phar and
>> there are other, custom solutions that I saw that use wrappers as base.
>> Maybe it would be a good idea also to pass a flag to stream_open saying it
>> is used for include - though it won't fix broken code of course.
>>
>
> Hi,
>
> There is just such a flag passed to wrapper_open (at least inside pecl
> streams, I imagine you're talking about user streams) but that most
> likely would not be secure at all, as it puts the onus on the streams
> implementor, which is the problem right now. This is why I suggested
> disabling all remote access while calling a stream's open and read for
> include purposes, it centralizes the security access inside the zend
> engine where it is possible to audit and easier to control.
>
> In my opinion, it would be a pity to lose the design benefits of stream
> wrappers in the effort to gain more security when security can be gained
> without losing the benefits. I think it would be good to allow
> disabling all urls as Stefan suggested, but if there is a way to
> restrict to truly local stream wrappers, I would need to be educated as
> to how this is less secure than outright disabling urls.
>
> Greg
>
>
