Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59486
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAORXhG+eg8kS9Xqyt4WdH0H5C6H5P09Uc9+U5LA0RWrs5iR5ow@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>
Date: Mon, 9 Apr 2012 16:01:40 +0900
Message-ID: <CAGa2bXbtJ3ksL_iaeZ0+DGU5veKegNRS0LY1s=zrZVNwLLvt7Q@mail.gmail.com>
To: Tom Boutell <tom@punkave.com>
Cc: 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: yohgaki@ohgaki.net (Yasuo Ohgaki)

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 inclus=
ion
>>>> >> became much harder than before. However, it's still possible and ve=
ry
>>>> >> easy compare to other languages. Script execution is critical secur=
ity
>>>> >> 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 =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 fil=
ter
>>>> > 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
>