Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83728
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54ED160B.9010908@gmail.com>
References: <CAGa2bXa=LHMT+wdSM_xbHDo1901QDSFa-KotjQckNwVX9wUEUQ@mail.gmail.com>
	<CAGa2bXZ0VCC4ZN0=YU8ZE9LXm8m9j-RJnmYOhd5qrENoa1HimQ@mail.gmail.com>
	<CA+9eiLvV-wY-6BC5FHZM=uMAWm4Ny4Ej_m2F31o6DNGacpfJPQ@mail.gmail.com>
	<CALwr1Gmmy06_4ZgsvUhcf5m7g06vK2s18qmxKBv1gu+syrsbQA@mail.gmail.com>
	<54ECD4E3.9040705@gmail.com>
	<CALwr1GkY_8TN-HwXnRNL0-1oRfQPJvz0_vyJv_ojUTVsFbkNTQ@mail.gmail.com>
	<54ECF605.7030506@gmail.com>
	<CALwr1GkU_mumpp-34Pp=gKwZzL3KVEW7JpEnqC5MMtcgM_qEbA@mail.gmail.com>
	<54ED160B.9010908@gmail.com>
Date: Wed, 25 Feb 2015 00:53:20 +0000
Message-ID: <CALwr1GnDW0OfAFfvbZhoa4iN_jt8GHJSyFA-jhhct+MRfrHYiA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	"internals@lists.php.net" <internals@lists.php.net>, Nikita Popov <nikitappv@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c34010c39426050fdf0fdc
Subject: Re: [PHP-DEV] [RFC] Script only include/require
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

--001a11c34010c39426050fdf0fdc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi

On Wednesday, February 25, 2015, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > Your example omitted the image validation step which would have
>
> Ah, right, and if I name it .zip, it'd be zip validation, and if I name
> it .pdf it'd be pdf validation, and if I name it .lol that would be LOL
> validation. You'd have to manually validate every type in existence and
> somehow invent validation for unknown ones. And it's not like I can't
> also make it a valid GIF/PDF/whatever - that has been done already. So
> you support this "security measure" by saying you can maybe plug the
> hole using other measures. Maybe you can, maybe (more probably) not but
> that does not redeem the insecurity of this "security measure".


Well, you fire those right over and then we'll have a debate worth having
;).


> > again. It's not very fair to create a scenario with a total lack of
> > any security, and then ignore that your code's problem is that gaping
> > hole and NOT the minor extension filter on the far end.
>
> But that is *exactly* what this RFC is doing! The gaping security hole
> is include $argv[1] and that's where it should be fixed, not introducing
> temporary patches that prevent 1% of the scenarios and can be overridden
> within minutes.


RFC does not target invalidated uploads. For heavens sake, it's a defense
in depth measure not a sentient AI!


> I don't see how it is not fair since the *only* scenario where it is
> useful is when your code *already* has the gaping security hole,
> otherwise this RFC has no utility as your includes are controlled by you
> so they already are php files.
>

That is not true! The lack of validation is one of degrees. You are
speaking in absolutes and ignoring partial effectiveness. Your example had
ZERO validation. Yasuo's clearly targeted successful validation of an
image. Not none at all.


> > indeed be preventable by his RFC. Please stick to what the RFC
> > actually claims to do.
>
> It claims to protect from file inclusion, by only allowing for include
> to operate on strings which end in .php, and then banning such files
> (ending in .php) from being handled by move_uploaded_file(). As I
> demonstrated (and this is I suspect not the only option) this does not
> actually offer any protection from LFI/RCE, as the end of the string
> given to include and the file on disk do not have to be the same. In my
> eyes, mechanism with such big BC break potential that is overridden in
> so trivial manner has little value.
>

No it doesn't! You are misrepresenting this RFC as a magic wand. That is
not the case and it is extremely frustrating to see you persist on this.
Read my emails and read Yasuo's and then Dan's. Then we can have some sort
of intelligible discussion.

Paddy



--=20

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

--001a11c34010c39426050fdf0fdc--