Re: Re: [RFC] No PHP tags

From: Date: Wed, 12 Feb 2014 07:15:40 +0000
Subject: Re: Re: [RFC] No PHP tags
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
Yasuo Ohgaki wrote:

    Have you actually looked at the 'Some recent LFI issues' that are listed? I
    don't thing any one of them would have been protected from by this change?
    Providing a php page that can DISPLAY or run any file that it can read is
    not going to be protected from by switching embedding off?


1st one is file upload vulnerability. I'll replace it something else.
2nd one is

http://seclists.org/bugtraq/2012/Apr/53

     $filepath = "$path_to_citrus/$load.php";
                 if (file_exists($filepath)) {
                         include('./'.$load.'.php');


I'm not sure what they are loading. script() prevents from reading /etc/passwd
or any other files.


Since it is loading a .php file there has to be a valid .php file to load? This is simply another file upload vulnerability?

3 and 4 as far as I can see expected the files being loaded to contain embedded php, and so the environment needed to be secured better and the application rewritten. I accept simply disabling php would have blocked the hole, but it also would stop the whole application working? Certainly onefilecms has been completely reworked and is no longer vulnerable ... as far as I can see ... I've not looked at the other app now.

I still don't see how - short of switching off embedding permanently - you will stop critics with ulterior motives from calling PHP insecure? Other than that one element, php is as at risk as the other languages. Once embedding is switched off either by calling the file using 'script()' ( which I view would transparently switch embedding off so not need any ini switch! ) or by the physical ini switch, then yes PHP is any other language, so if they are so worried about it ... use something else?

I could almost be convinced about the 'script()' option, but I would then insist the loaded file HAD <?php at the top and any other php tag would flag an error. It was loosing that 'security blanket' in the other rfc that grated ... but I don't see the point of the ini switch unless at some point you want to disable embedding permanently :(

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Thread (37 messages)

« previous php.internals (#72500) next »