Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72500 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91162 invoked from network); 12 Feb 2014 07:12:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Feb 2014 07:12:17 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:48530] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BC/13-07280-0DE1BF25 for ; Wed, 12 Feb 2014 02:12:16 -0500 Received: (qmail 13887 invoked by uid 89); 12 Feb 2014 07:12:13 -0000 Received: by simscan 1.3.1 ppid: 13880, pid: 13884, t: 0.1051s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 12 Feb 2014 07:12:13 -0000 Message-ID: <52FB1F9C.9090609@lsces.co.uk> Date: Wed, 12 Feb 2014 07:15:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 MIME-Version: 1.0 To: "internals@lists.php.net" References: <52FA67A4.3030708@lerdorf.com> <52FAB58E.3080701@lsces.co.uk> <52FB0920.8040903@lsces.co.uk> <52FB0D15.9040303@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags From: lester@lsces.co.uk (Lester Caine) 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