Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59488
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbtJ3ksL_iaeZ0+DGU5veKegNRS0LY1s=zrZVNwLLvt7Q@mail.gmail.com>
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com>
	<CAGa2bXYP0kNA5PyvmdjoHZO91t8AojG9FjUe4nbCHhGjn2=MPg@mail.gmail.com>
	<4F80C739.2060404@gmail.com>
	<CAGa2bXZSgV3bRPGMt6Esw16v3ErVMLVQy1fb8cZxdc=OokpXKg@mail.gmail.com>
	<CAL0xaBEpjhwTMFknx9nPYXqFGOqM9f2xRiBhcdb8NtPCsVL6sg@mail.gmail.com>
	<CAGa2bXaEZ1rkkQ1MTCQ8=eet9P9oAWXz-cPMe5wRhHfFJE8N8Q@mail.gmail.com>
	<CAORXhG+eg8kS9Xqyt4WdH0H5C6H5P09Uc9+U5LA0RWrs5iR5ow@mail.gmail.com>
	<CAGa2bXbtJ3ksL_iaeZ0+DGU5veKegNRS0LY1s=zrZVNwLLvt7Q@mail.gmail.com>
Date: Mon, 9 Apr 2012 10:20:28 +0300
Message-ID: <CAL0xaBGGFRqq9tkc33daKoqTNHsLNmgadkUEjJtrGGJsWfK+YQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP Internals <internals@lists.php.net>, Tom Boutell <tom@punkave.com>
Content-Type: multipart/alternative; boundary=e89a8f235a293ee96b04bd39d7e5
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--e89a8f235a293ee96b04bd39d7e5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

And you get same issues that existed with magic quotes, register variables,
safe mode and other optional stuff that was required to run application
when set specificaly and it would break if something set differently. PHP
just got rid of it and you want to introduce a new optional feature that
will change how PHP behaves.
09.04.2012 9:03 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C "Yasuo Ohgaki" <yohgaki@ohgaki.net> =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:

> Hi,
>
> 2012/4/9 Tom Boutell <tom@punkave.com>:
> > Vulnerabilities in include/require should be fixed there, IMHO, not by
> > limiting the feature set of the language.
>
> I'm not insisting to remove embed feature, but give a option
> for programmers/administrators for better security.
>
> If one is comfortable with current behavior, they can keep
> using embed feature by default. Others who care security
> may disable embed feature by optional php.ini setting or CLI
> option.
>
> Half of Morihoshi's RFC was joke, but it's a serious proposal
> for people who persist  better security. IMHO.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
> >
> > On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote=
:
> >> Hi,
> >>
> >> 2012/4/9 Arvids Godjuks <arvids.godjuks@gmail.com>:
> >>> 8 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3. 8:16 =D0=BF=D0=BE=
=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Yasuo Ohgaki <=
yohgaki@ohgaki.net
> >=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> >>>
> >>>> 2012/4/8 =C3=81ngel Gonz=C3=A1lez <keisial@gmail.com>:
> >>>> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
> >>>> >> Hi,
> >>>> >>
> >>>> >> The only valid reason for removing <?php from PHP script would be
> >>>> >> security.
> >>>> >>
> >>>> >> Since the null byte detection for fopen, remote/local script
> inclusion
> >>>> >> became much harder than before. However, it's still possible and
> very
> >>>> >> easy compare to other languages. Script execution is critical
> security
> >>>> >> problem and it's worth to make it better.
> >>>> >>
> >>>> >> If there is a switch that turns off PHP's template engine nature,
> PHP
> >>>> >> could be more secure than now.
> >>>> >>
> >>>> >> php.ini
> >>>> >> template_mode =3D on   ; INI_ALL On by default
> >>>> >>
> >>>> >> php -t foo.php   # template mode by default
> >>>> >> php -T foo.php  # template mode off
> >>>> >>
> >>>> >> People has option to make their code a little secure than now
> >>>> >> or stick with current behavior.
> >>>> >>
> >>>> >> Regards,
> >>>> > How does it help security?
> >>>> > If any, requiring '<?php' before executable code makes easier to
> filter
> >>>> > out malicious files on apps with uploads in case there's a local
> >>>> > inclusion vulnerability somewhere.
> >>>> >
> >>>>
> >>>> Attackers may inject PHP script almost anything/anywhere since
> >>>> PHP code may be embed anywhere in a file.
> >>>>
> >>>> For example, malicious PHP script may be in GIF something like
> >>>>
> >>>> gif89a ...any data.. <?php exec('rm -rf /') ?>
> >>>>
> >>>> and all attacker have to do is include/require the data somehow.
> >>>> Attacker cannot do that this for other languages, since they are
> >>>> not a embedded language. I know case that attackers may inject
> >>>> malicious perl/ruby script in data files, but PHP is too easy
> >>>> compare to these languages.
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Yasuo Ohgaki
> >>>>
> >>>> --
> >>>> PHP Internals - PHP Runtime Development Mailing List
> >>>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>>
> >>>>
> >>> Improperly configured WEB server is not the reason to change the most
> basic
> >>> part of the language that will break every damn application out there=
.
> >>
> >> This is not an configuration issue, but a security vulnerability that
> >> can simply closed by disabling embed mode.
> >>
> >> As I mentioned already, injecting malformed PHP scripts into files
> >> is too easy compare to other languages. This could be improved
> >> by simple modification and we can maintain compatibility with it.
> >>
> >> I don't see anything wrong here.
> >>
> >> Yet another PHP script injection example.
> >> There are many applications that store user inputs in $_SESSION.
> >> Attacker can inject PHP script into $_SESSION, then locally include
> >> it. This is easy since attacker knew their session ID and path to
> >> session file is can be guessed easily. All attacker has to do is
> >> finding a vulnerable include()/require() to attack.
> >>
> >> Regards,
> >>
> >> --
> >> Yasuo Ohgaki
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> >
> >
> > --
> > Tom Boutell
> > P'unk Avenue
> > 215 755 1330
> > punkave.com
> > window.punkave.com
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--e89a8f235a293ee96b04bd39d7e5--