Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72485
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52FA67A4.3030708@lerdorf.com>
References: <CAGa2bXYU0+eVgnDCkqpG6AWvLCX9gV3+5nzoeD-RJge8Rtw-dQ@mail.gmail.com>
 <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com> <52FA67A4.3030708@lerdorf.com>
Date: Wed, 12 Feb 2014 08:13:30 +0900
Message-ID: <CAGa2bXaHTCx+8=BJH-L+KqANo9NtEML3cp2sJqgv1jmGLYXaGg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e012297101e987504f2299d94
Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e012297101e987504f2299d94
Content-Type: text/plain; charset=UTF-8

Hi Rasmus,

On Wed, Feb 12, 2014 at 3:10 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 2/11/14, 9:42 AM, Yasuo Ohgaki wrote:
> > Let me rephrase. Does anyone argue that the fact
> >
> > Local script inclusion is *much grater security threat* than local script
> > expose.
> >
> > "Local script expose" is the only drawback of this RFC.
> > Currently, insecure include()/require() allows script execution.
> > With this RFC, insecure include()/require() may allow script expose.
> >
> > Latter is obvious error as it shows wrong behavior while script execution
> > is
> > not obvious at all. If user care to script expose, they can simply add
> > "<?php"
> > at the top of script as it is now.
> >
> > We can make secure program with register_globals=On as well as embed
> > everything by default. The same argument applies here. IMHO.
>
> You need 2 things to go wrong though. 1st, you need a way for someone to
> upload arbitrary files, and second, you need a include $_GET['filename']
> somewhere. However, if you think about it, the include part is
> completely secondary, if you can upload arbitrary files you can just
> request them directly in order to execute them so the include part is
> irrelevant.
>

I'm aware of this issue. That's the reason why I added
script()/script_once()
to original proposal. (include()/require() works as it is now. For
compatibility,
users may simply wrap include() to have script() for older PHP)

Or, if you remove the arbitrary upload part you are down to only being
> able to include already existing files but most files don't actually do
> anything on their own. PHP files tend to either be top-level template
> files designed to be shown to the user, or they contain functions or
> classes which do nothing until called. The act of including them
> typically doesn't actually execute any code. So yes, in my view script
> exposure is a more serious problem than script execution from an
> insecure include so your suggested change would make things worse, not
> better.


Attackers can use script inclusion to do anything, including reading
scripts and
any other security sensitive files. They can do more than reading with LFI.
Therefore, LFI is worse than script exposure to me.

I like the way PHP works. Embedded script nice for web applications and we
should not drop it, but it's better for security  if it is restricted to
only where
it is needed.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e012297101e987504f2299d94--