Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59495
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.216.170 as permitted sender)
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> <CAL0xaBGGFRqq9tkc33daKoqTNHsLNmgadkUEjJtrGGJsWfK+YQ@mail.gmail.com>
In-Reply-To: <CAL0xaBGGFRqq9tkc33daKoqTNHsLNmgadkUEjJtrGGJsWfK+YQ@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-A886BD96-3082-4819-B637-AFE41F18CE39
Message-ID: <1A4475FB-0ECC-460E-813F-209BA57A2DCE@punkave.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>,
 PHP Internals <internals@lists.php.net>
Date: Mon, 9 Apr 2012 06:48:22 -0400
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: tom@punkave.com (Tom Boutell)

--Apple-Mail-A886BD96-3082-4819-B637-AFE41F18CE39
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree, which is why the rfc does not call for a php.ini option.

Sent from my iPhone

On Apr 9, 2012, at 3:20 AM, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:=


> And you get same issues that existed with magic quotes, register variables=
, safe mode and other optional stuff that was required to run application wh=
en 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 ch=
ange how PHP behaves.
>=20
> 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,
>=20
> 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.
>=20
> I'm not insisting to remove embed feature, but give a option
> for programmers/administrators for better security.
>=20
> 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.
>=20
> Half of Morihoshi's RFC was joke, but it's a serious proposal
> for people who persist  better security. IMHO.
>=20
> Regards,
>=20
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>=20
>=20
> >
> > 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 <yohg=
aki@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 inclu=
sion
> >>>> >> became much harder than before. However, it's still possible and v=
ery
> >>>> >> easy compare to other languages. Script execution is critical secu=
rity
> >>>> >> problem and it's worth to make it better.
> >>>> >>
> >>>> >> If there is a switch that turns off PHP's template engine nature, P=
HP
> >>>> >> 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 fi=
lter
> >>>> > 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 b=
asic
> >>> 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
> >
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

--Apple-Mail-A886BD96-3082-4819-B637-AFE41F18CE39--