Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59542
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <4F833AB0.2060306@sugarcrm.com>
References: <CAORXhGJwmbjw3Zze3+-oFA2Mb_Z-2owVESraNMMs57RzjRRMbA@mail.gmail.com>
 <-5877502932356715576@unknownmsgid> <CAORXhGLPdAie6UFq+daJhUmDUqp7RaFFLa596XdzdtuCddf0Jw@mail.gmail.com>
 <-3647345967307864634@unknownmsgid> <CAORXhGKjg_L11dFGNHNfNygDH018=ZhytAy1vH+Ei8QHfry=cA@mail.gmail.com>
 <CAORXhG+K3XML-47+FDYdL5D717wDX7c59Pz8KgqjcP16+Ad12w@mail.gmail.com>
 <4F831FAE.2030208@ralphschindler.com> <4775322189440202047@unknownmsgid>
 <CAORXhGJSG6CJD5EAt_uZ7RjfjM345nfrVQz8t2ep4e3WhCeKMQ@mail.gmail.com>
 <4F833682.2000301@ralphschindler.com> <CAGa2bXYjJsfo6os_P1OvQ7jfmxeYUkZ+QK5r94nwNUsba-iWLA@mail.gmail.com>
 <4F833AB0.2060306@sugarcrm.com>
Date: Tue, 10 Apr 2012 05:15:00 +0900
Message-ID: <CAGa2bXZQN9brCwHOOkDU+x3hf5dZgqqmv1ZSTJ3VMjSpdda6tA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Ralph Schindler <ralph@ralphschindler.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] RFC: source files without opening tag
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

2012/4/10 Stas Malyshev <smalyshev@sugarcrm.com>:
> Hi!
>
>> Tom's FRC is trying to introduce tag less PHP script.
>> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
>> IMHO, this change introduce more complexity and do not solve
>> any problem.
>
> I'm not sure I follow - which PHP vulnerability you are talking about?

Not many people read RFC, so I should have written example attack scenario.
Because PHP is embedded scripting language, PHP code may be embedded
anywhere/any files. One convenient place is session storage. i.e. file
save handler.

==Exploiting LFI without file uploads==

1. Find FLI vulnerable application.
2. Find a way to inject $_SESSION
3. Use session file to execute arbitrary PHP code.

Files save handler is the default, attacker knew his/her session ID and
can guess session.save_path easily. Therefore, there are high possibility
that attacker could take control of web server via LFI.

== Possible protections ==

It's possible to prevent session FLI by adding "<?php die()?>" to top
of session  data. It's not clean solution and has compatibility issue with
other systems. (e.g. There are PERL/Ruby/Python scripts that decodes
PHP session data) It's also possible that makes save_path unpredictable.
It won't worth to do that. IMO.

If developers/administrators could make PHP tag non mandatory, almost
all LFI could be protected by simple file validation. i.e. Check the first line
if it begins with "<?php"


== Validation Issues ==

Invalidating PHP script contained file is not simple. Attacker can inject
PHP code into any file and anywhere.

1. "<?", "<%" may occur in binary
2. <script language= is common in HTML

Forcing programmers to check binary/HTML/mail messages/etc would be
impossible.

== Solution ==

Please take a look at the RFC.
https://wiki.php.net/rfc/nophptags

Regards,


--
Yasuo Ohgaki
yohgaki@ohgaki.net