Hi, First of all, the proposal is threat mitigation and not for a complete countermeasure for LFI.
2012/4/10 Ferenc Kovacs <tyr...@gmail.com>: >> >> "allow_url_include" and "template_mode" is similar to me. >> >> allow_url_include: enable only when url include is needed. >> template_mode: enable only when template mode is needed. >> >> allow_url_include prevents RFI which may result in critical security >> incident. >> template_mode prevents LFI which may result in critical security incident. >> >> Note: template_mode=off is script only mode. On is current behavior. >> > > I just glanced over the RFC. > See my comments below: > "LFI/RFI is fatal security error. Currently, LFI prevention is upto > programmers and framework authors/system admins do not have feasible way to > prevent LFI" > what about open_basedir? It's mitigation feature like template_mode=off. > > "Current PHP is weak to script injections compare to other languages such as > Ruby/Perl/Phthon/Lua/etc." > would be nice listing what does those languages do better in thise regard. > AFAIK ruby allows you to include arbitrary files, and the rails security > guides even mention the file upload > vulnerability: http://guides.rubyonrails.org/security.html#executable-code-in-file-uploads > perl also have require, Python has import, which is maybe a little bit > harder to misuse, lua has both dofile and require. > it would be nice explaining what do you mean by php being week compared to > those languages. I know these language/framework may have similar vulnerability even Java had. What I would like to point out it "LFI in PHP is *very* easy with respect to other languages due to embedded language nature". We can tell it from number of CVEs for LFIs. That's the reason why there would be better to have additional protection. > "PHP script inclusion detection may be done for data files. However, it's > not a simple task." > as I mentioned before, I don't think that it is the good way to try to > detect the injected code in the data files: > one should know beforehand that whether is the uploaded file is meant to be > a data file or a script file, and act accordingly. > > "Almost all applications are not checking these and it would be impossible > to make developers do a proper validation." > these kind of filtering techniques are error prone. Agreed. > > "Disabling embed(template) mode is simple solution for this issue." > one can still upload valid embed files and if the LFI is present, execute > those. > > so your solution would only improve this problem, if an LFI vulnerability is > present or the uploaded files are publically accessible and not excluded > from the execution and the file uploads otherwise properly type validated > and the developer choses to be compatible with the template_mode off and > disables it(as the default would be on). Yes, it should be considered as mitigation. However, it is good one. > I think that it would be really hard to adopt. Framework developers are > trying to support the widest audience, and supporting both template_mode On > and Off will be a major PITA imo. As I wrote in RFC example, supporting both is simple. 1. Disable template_mode=off in bootstrap, if they would like to enjoy mitigation. 2. Enable template_mode before render. 3. Disable template_mode after render. For good frameworks, it will be a few lines of changes. > and until they do, the average developer can't be expected to make his > choice of framework compatible with template_mode off, so he/she won't use > it. It would be easy enough for framework users to adopt template_mode. So they can make changes to framework. Perhaps, they could contribute it. > I think it would require far less work to find and fix the LFIs and properly > configure the webserver than rewriting your whole application (including > your libraries). > > IDEs would be in the same spot, they can't tell you that whether or not your > file is missing the opening tags without looking into your php.ini/apache > vhost/.htaccess config. > it can be either fine or a bug, depending on the value of template_mode I think you have missed RFC spec. Even when template_mode=off, "<?php" at the beginning of script file is allowed for compatibility. > as Stas pointed out, if you migrate your codebase which depends on > template_mode = Off, and you forgot to change the default php.ini (yeah, you > should notice this before going live, but we are talking about the people > having LFI and other vulns...) then your files will be served by your > webserver as is. which itself can compromise your system. I think this could be verified easily by find and grep or IDE search. Modern script would not have needless PHP files under docroot also. > "With this RFC, the only allowed PHP tag under non embed mode is ”<?php”." No. <?php <? <% and others are allowed. Anyone wants <script language="php">? > oh, isn't that contradicting "This RFC proposes removal of PHP tags (<?php > and so forth) from the PHP script by php.ini or CLI option flags." and "Not > a few programmers may once have been bothered to put a PHP tag at the top of > every PHP script that only contains classes and functions. In short, PHP > tags are just ancient." > although it would lessen the BC/incompatibility problems mentioned above. Thanks for catching it. It was written for April Fool day by Moriyoshi. I should have edited his joke :) > > In general I'm -1 on this RFC, I think that the people who are vulnerable > wouldn't use it, and there are better alternatives for the described > problems than the introduction of template_mode. Are there? I should have missed. What is the better alternative? > this would add an additional level of complexity and would make it harder to > write portable code. This is misunderstanding. You might be felt by the part of April Fool's joke. I'll edit the part from now and please reconsider. Regards, -- Yasuo Ohgaki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
