Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59475
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: <CAL0xaBEpjhwTMFknx9nPYXqFGOqM9f2xRiBhcdb8NtPCsVL6sg@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>
Date: Mon, 9 Apr 2012 06:34:05 +0900
Message-ID: <CAGa2bXaEZ1rkkQ1MTCQ8=eet9P9oAWXz-cPMe5wRhHfFJE8N8Q@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: PHP Developers Mailing List <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 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 inclusio=
n
>> >> became much harder than before. However, it's still possible and very
>> >> easy compare to other languages. Script execution is critical securit=
y
>> >> 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 =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 filte=
r
>> > 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 bas=
ic
> 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