Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83756 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79590 invoked from network); 25 Feb 2015 09:52:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2015 09:52:37 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:38014] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AD/83-62407-26B9DE45 for ; Wed, 25 Feb 2015 04:52:35 -0500 Received: (qmail 22412 invoked by uid 89); 25 Feb 2015 09:52:31 -0000 Received: by simscan 1.3.1 ppid: 22403, pid: 22409, t: 0.0976s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 25 Feb 2015 09:52:31 -0000 Message-ID: <54ED9B5F.60006@lsces.co.uk> Date: Wed, 25 Feb 2015 09:52:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <54ECD4E3.9040705@gmail.com> <54ECF605.7030506@gmail.com> <54ED8E9F.80803@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Script only include/require From: lester@lsces.co.uk (Lester Caine) On 25/02/15 09:14, Yasuo Ohgaki wrote: > Hi all, > > On Wed, Feb 25, 2015 at 5:58 PM, Lester Caine wrote: > >>> As soon as you have any possibility of including a file uploaded by an >>> attacker, you are probably going to lose. >> >> I think that this is perhaps the key here. > > > I thought it's rather obvious how this RFC works, but apparently not. > I added following description to the RFC. > > ============================================== > Do not see how this RFC prevent script inclusion attacks > > - include*()/require*() refuse to compile/execute file extensions other > than “.php .phar” by default. > - move_uploaded_file() refuse to move PHP script. “.php .phar” is refused > by default. > > With this RFC, include*()/require*() only executes files have “.php” or > “.phar” extension and move_uploaded_file() refuse to move uploaded files > that can be executed as PHP script. Therefore, even most obvious mistake > like 'include $_GET[“var”];' will not work anymore. i.e. It cannot read > files like “include '/etc/passwd';” nor execute script like “include > '/path/to/upload/evil_image.jpg';”. > ============================================== > > How could this RFC loose? > > I'm not trying to protects users from shooting themselves. > However, this RFC protects PHP programs from script inclusion attack > as well as file inclusion attack via include/require by default. Totally understand what you are trying to do, and if the users you are trying to protect actually downloaded PHP direct from the PHP site it may stand a chance of actually doing that, but it's adding restrictions that WILL break other distributions so either they have to re-work what they do, or switch it off anyway. The people you are trying to protect are going to be downloading a distribution that may well be using 'obvious mistakes' such as .inc or .php5 in addition to .php There have been attempts in the past to make 'script only' files and and these same sort of restrictions, but the fallout did prove more of a problem. Example ... one of the legacy sites I just had to move stopped doing any of the navigation stuff and would not send a contact email. Was working fine previously ... but when I actually started looking at the code strangely the pages were all .html ... yep ... a complex site with lots of content which had originally been hand coded and at some point a few little bits of php had been added in. My nginx setup had disabled processing .html pages so broken site. I don't want to rename all of the files to .php ... I don't need to ... so I've created a php-fpm for .html only and we are working again. Only a few hours wasted but the sort of thing we have to be able to cope with! -- 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