Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59645
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGsnKxZU1ui+VxXNY1K7iBEAMwLNknVUJ3Rc+-rD_coDV3sNdg@mail.gmail.com>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
	<CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
	<CAGsnKxZU1ui+VxXNY1K7iBEAMwLNknVUJ3Rc+-rD_coDV3sNdg@mail.gmail.com>
Date: Tue, 10 Apr 2012 16:35:19 +0200
Message-ID: <CAH-PCH4Y7EqDvT+mN1M00RF5VwPYGg_aYmMQFjut+iYq47BGzQ@mail.gmail.com>
To: John LeSueur <john.lesueur@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b11190b3c0fd204bd540885
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b11190b3c0fd204bd540885
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 3:36 PM, John LeSueur <john.lesueur@gmail.com>wrote=
:

> 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?


http://web.nvd.nist.gov/view/vuln/search-results?query=3Dphp+inclusion&sear=
ch_type=3Dall&cves=3Don


> 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 =3D ini_set('open_basedir', '/some/base/dir');
> include "/some/base/dir/$file";
> ini_set('open_basedir', $origBasedir);
>

I think safeinclude wouldn't set open_basedir(as you can only tighten the
basedir restriction currently), but simply check against the allowed
path(s) and include the file if the path matches the whitelist, and that is
easily achievable from userland already.
On the other hand, if you would like to "jail" a piece of third party code,
having the ability to set the open_basedir for that codeblock would be
handy, so maybe this would be worth evaluating.

call_user_func_jail(
  function() {
    return call_third_party_insecure_app();
  },
  '/var/www/'.PATH_SEPARATOR.'/tmp/'
);


>
> 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? (y=
ou
> mentioned some CVE's related to it, can you point them out?)
>

see above


> 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?
>

I think it is, so those who need it most wouldn't use it imo.


> 3. Aren't there better options for protection against LFI?
>

as I wrote in my previous email on this topic, I think that proper user
input validation (including the file uploads, and properly restricting the
execution of the uploaded files) and already present additional hardening
options (open_basedir, allow_url_include) should be enough to prevent any
kind of LFI/RFI vulnerabilities if properly used.
I think it would be better idea to promote those techniques instead of
adding another somehow obscure option which wouldn't be used by the target
audience, but would be abused.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b11190b3c0fd204bd540885--