Hi Stas,
On Wed, Feb 25, 2015 at 9:52 AM, Stanislav Malyshev <smalys...@gmail.com>
wrote:
> > - require/include only includes ".php" ".phar" by default.
>
> This is not true. As I repeatedly point out, your change only requires
> that the string passed to include would end in .php, but string passed
> to include and filename on filesystem are very different things, they do
> not have to be the same at all!
>
> > - move_uplaoded_file() only move files other than ".php", ".phar"
> > extension by default.
> >
> > This makes "script inclusion" attack much harder. In fact, this RFC
> > makes almost
> > impossible attackers to take advantage of PHP's embed everything nature.
>
> I am at loss how you can claim it is "impossible" after I just
> demonstrated how it is possible.
>
> > For users do not need these protections, they can simply add one liner.
> >
> > ini_set('zend.script_extensions', '');
> >
> > This piece of code is executed for all PHP version without any errors.
>
> You sincerely do not understand why breaking all code that uses non-php
> extensions is a problem and that editing existing production code's
> entry points is by no way "simple"? That finding all extensions that may
> be used for files in a complex software is very far from "simple"?
>
> > Unlike previous RFC, this RFC patch does not care "contents" of file, but
> > only cares file "extensions". However, it works well as described before.
>
> It doesn't work well - in fact, it does not work at all, as I just
> demonstrated, exactly because extension of the actual file and what
> you're checking are different things.
>
> > Even with this RFC, users can shoot their own foot and PHP is much easier
> > to do it wrong compare to other languages.
>
> These platitudes do not change the simple fact that your RFC does not do
> what it claims to do, security-wise.
>
> > However, if users use new PHP by default setting, PHP is as safe as
> > other languages against script inclusion/upload attacks. Since we have
> > move_uploaded_file() protection, PHP becomes safer than others.
>
> No, it does not become safer, because if you have code that allows
> script inclusion injection (and if you do, it's your fault, not PHP's)
> it is trivial to exploit it even with this RFC.
>
> > - require/include cannot load script other than ".php"/".phar".
>
> As I showed, this is not true. I am kind of tired of repeating the same
> thing again and again and being completely ignored, so unless there's
> some new argument I'll stop repeating myself now.
I think you misunderstood the RFC.
You seems forgetting about "allow_url_include=Off" by default.
Are you saying current PHP allows
include('zip://...') or include('input://...')?
Then this is serious bug. I'll fix it also.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
