Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59643
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
	<CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
Date: Tue, 10 Apr 2012 07:36:48 -0600
Message-ID: <CAGsnKxZU1ui+VxXNY1K7iBEAMwLNknVUJ3Rc+-rD_coDV3sNdg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=00504502d19aeb949c04bd533691
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: john.lesueur@gmail.com (John LeSueur)

--00504502d19aeb949c04bd533691
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 4:51 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> I've written most of thing that I would like to mention for this RFC.
> I tried to be precise and understandable for anyone. If you have
> questions, you are welcomed both on this list and in private.
>
> Regards,
>
> P.S. Directly fixing bad English on wiki is certainly appreciated.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm still unclear how LFI is a real concern. I have yet to see a sane
example of code that is vulnerable. No one should ever write:

include $_REQUEST['var'];
include $_SESSION['var'];
include $varFromDb;

Do you have an example of real-life modern code that is vulnerable? The
closest I've seen is some form of front controller:

$pathParts = implode('/', $_SERVER['PATH_INFO']);
$controllerClass = 'Controller' . $pathParts[0];
$controller = new $controllerClass;

which then in the autoloader, uses the class name to include the file.
Depending on the autoloader implementation, this is either invulnerable to
LFI, or very, very unlikely to be exploitable.

Now, as a webserver admin, maybe you have someone writing code that you
don't trust, and can't control. I don't see how an optional non-embedded
mode solves that problem, since it is a voluntary measure?

Someone mentioned open_basedir as a mitigation, and I feel it is superior,
since an admin can impose it without having to rely on voluntary
compliance. If you want something stronger, then why not create something
like:(note: this is not a real proposal)

safeinclude "/some/base/dir", $file;

which is equivalent to

$origBasedir = ini_set('open_basedir', '/some/base/dir');
include "/some/base/dir/$file";
ini_set('open_basedir', $origBasedir);

which allows the developer to specify where he expects the file to be, so
that attackers can't manipulate the filename to access any location they
want.

summary:
1. Is there an example of modern, sane code that is vulnerable to LFI? (you
mentioned some CVE's related to it, can you point them out?)
2. Isn't embedded vs. non-embedded mode a voluntary measure, thus not
protecting those inexperienced enough to write code that is vulnerable to
LFI?
3. Aren't there better options for protection against LFI?

--00504502d19aeb949c04bd533691--