Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59478
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaEZ1rkkQ1MTCQ8=eet9P9oAWXz-cPMe5wRhHfFJE8N8Q@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>
Date: Sun, 8 Apr 2012 18:11:21 -0400
Message-ID: <CAORXhG+eg8kS9Xqyt4WdH0H5C6H5P09Uc9+U5LA0RWrs5iR5ow@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: tom@punkave.com (Tom Boutell)

Vulnerabilities in include/require should be fixed there, IMHO, not by
limiting the feature set of the language.

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 <yoh=
gaki@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 inclusi=
on
>>> >> became much harder than before. However, it's still possible and ver=
y
>>> >> easy compare to other languages. Script execution is critical securi=
ty
>>> >> problem and it's worth to make it better.
>>> >>
>>> >> If there is a switch that turns off PHP's template engine nature, PH=
P
>>> >> could be more secure than now.
>>> >>
>>> >> php.ini
>>> >> template_mode =3D on =C2=A0 ; INI_ALL On by default
>>> >>
>>> >> php -t foo.php =C2=A0 # template mode by default
>>> >> php -T foo.php =C2=A0# 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 filt=
er
>>> > 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 ba=
sic
>> 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
>



--=20
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com