On Tue, Apr 10, 2012 at 10:54 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi, > > First of all, the proposal is threat mitigation and not for a > complete countermeasure for LFI. > yep, and I think that there is no transparent solution which would make impossible to havi LFI vulnerability without seriously crippling the language. > > 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. > I think it should be mentioned, because now it sounds from the RFC that there is nothing available in this regard. > > > > > "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. > maybe. but it can be accounted for other factors (like the popularity of the language, or the difference in the skill/knowledge of the average php developer/application vs the other languages). so I think it would be nice to explain what are those technical advantages the other languages have over php, instead of jumping to conclusion based on the number of the CVE numbers. > > 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. > ok, so this would be an PHP_INI_ALL setting. of course if you would like to use this feature to prevent the injection of php code to the data files(and the execution), you should still have to disable the php_engine on the upload directory (or enable template_mode for that dir at least) so we can say that for public accessible/executable user uploads, this feature can't do much. > > > 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. > yeah, I only noticed this later on, and didn't bothered to correct here. > > > 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. > yeah, but it is still a problem, that your IDE will be a hard time to properly catch. currently the <?php ?> tags are always available, if your RFC get's accepted, this can be turned off by runtime. > > > "With this RFC, the only allowed PHP tag under non embed mode is > ”<?php”." > > No. <?php <? <% and others are allowed. > yeah, this was another inconsistency in the RFC. > Anyone wants <script language="php">? > personally I don't. at all. > > > 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 :) > I think it would be better to leave as is, and create a separate RFC from the scratch, so that we don't have issues like this. > > > > > 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? > personally I wouldn't need a solution which could in some but not all cases save me from my security bugs. this would be abused like safe_mode and magic_quotes was. false sense of security, which would make people lazy about fixing the real problem (LFI/RFI, executable file uploads, etc.) > > > 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. > I will re-read it tomorrow. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
