On Tue, Apr 10, 2012 at 3:36 PM, John LeSueur <john.lesu...@gmail.com>wrote:
> On Tue, Apr 10, 2012 at 4:51 AM, Yasuo Ohgaki <yohg...@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 > > yohg...@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=php+inclusion&search_type=all&cves=on > 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); > 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? (you > 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
