On 25/02/15 09:14, Yasuo Ohgaki wrote:
> Hi all,
> 
> On Wed, Feb 25, 2015 at 5:58 PM, Lester Caine <les...@lsces.co.uk> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to