Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83862
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54EE5A39.9040401@gmail.com>
References: <CAGa2bXbt9FAdRtW1GxDyT+G-4bWBACTso_DOizcSHmmgmSVtmA@mail.gmail.com>
 <CAGa2bXb5QEKOggRbUnmVHuib=P_tJ9_W+QyMa_SCpc7RmSCgSA@mail.gmail.com>
 <54EE50CF.9090508@gmail.com> <CALwr1GmoAxfbKvJYVLeL3wPXEKKbu1jKGkTFcG0KQ_Ogx172sA@mail.gmail.com>
 <54EE5A39.9040401@gmail.com>
Date: Thu, 26 Feb 2015 10:48:49 +0900
Message-ID: <CAGa2bXYWQCZA8_-EpQcb_Af7DT-_FV7HdfAHZrVt4V7i7vEURg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: =?UTF-8?Q?P=C3=A1draic_Brady?= <padraic.brady@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114335006c6d66050ff3f6dc
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a114335006c6d66050ff3f6dc
Content-Type: text/plain; charset=UTF-8

Hi Stas,

I think you mean I ignored this. Let's discuss it.

============================================
> They'd need to upload with a matching file type. Instead of any file

Not sure what you mean by that. phar can read tars, etc. AFAIK, can't
it? Also, phar archive has no requirement of being named something.phar,
afaik can be also named cuteponies.gif. E.g., I just did this:

1. Created file chump.php:

<?php

include $argv[1];

This is an idealized vulnerable script.

2. Created file pwnd.php
<?php

echo "pwnd!";

This is an idealized exploit.

3. Put it into an archive:
tar cvzf cuteponies.gif pwnd.php

4. Run this:

php -dallow_url_include=0 chump.php phar://cuteponies.gif/pwnd.php

The output is:

pwnd!

I'm not sure how this measure would protect from such scenario. Am I
missing something here?
============================================

This can be prevented by restricting phar archive name or forbid all
URI name at all. The latter is better choice.

The root cause of this is the way "allow_url_include" is implemented.
"allow_url_include=Off" should disallow any type of URI include in the
first place. As you know, PHP can have custom loaders that use
URI form. Therefore, any kinds of custom loaders can be enabled by
modules. It's a nightmare for security standpoint.

There is design problem obviously. The reason why phar:// is allowed is
that "allow_url_include" is not INI_ALL.

http://php.net/manual/en/filesystem.configuration.php

Script cannot change the setting, therefore special phar:// is needed to
be allowed unconditionally. I would say INI_SYSTEM for allow_url_include
is false sense of security. It introduced security issue like you've
mentioned.

To resolve issues with custom loaders, we need to change the design.
This kind of *design mistake* is better to be fixed anyway.

I don't mind to write another RFC and implement it.

What do you think?

Regards,


--
Yasuo Ohgaki
yohgaki@ohgaki.net

On Thu, Feb 26, 2015 at 8:26 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> Padraic, I'm not really interested in another prolonged discussion,
> especially where my arguments are ignored or misconstrued and then
> dismissed. I have explained my opinion, if somebody has questions about
> the substance of my arguments or need me to clarify my points, rather
> than flat-out denial of what I am saying, they know where to find me. I
> think this RFC is bad. You think it's excellent. I tried to explain my
> point to you, judging by your responses, I failed to convey my meaning.
> I am probably bad at this, but I'm not going to become better by
> repeating the same over and over.
> I don't see what else I can do here - if majority of people would agree
> with you, we'll have another bad security feature in PHP, and will have
> to deal with it for the next decade, just as we had to suffer the safe
> mode problems. I hope this will not happen, but I really don't see what
> else I can say, provided that what I already said - including
> demonstrating trivial workarounds that allow to circumvent this feature
> with extreme ease - had no effect.
>
> > Is there some sort of meter on Internals where, in the red, there is
> > an obligation to fill it back up with FUD, logical fallacies and the
> > occasional fib?
>
> I also would really like for you to stop accusing me of lying. I may be
> mistaken, and I am sure I have been many times, but everything I write
> here is a product of careful consideration and thought, and aimed at
> making PHP better. The next instance you do this, I'm not going to
> reply, I'm just going to delete all following communications from you,
> from that point, forever. I can handle very spirited technical
> disagreement, I'm not new on the internet, but I do not see what use
> would be for me to spend my time on being insulted. There are a lot of
> more productive uses of my time. If there's no mutual respect here, then
> the chance of productive cooperation is nil. I hope we can hold
> respectful discussion, even when disagreeing. But if not, then I won't
> participate in any other kind.
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a114335006c6d66050ff3f6dc--