Hi Stas,
On Wed, Feb 25, 2015 at 7:26 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:
> > I would like to add a note for this.
> > Anti Virus products are detecting this type of files as "PHP malware".
>
> It looks like you are trying to convince me that PHP malware exists. I
> would like to save you time by notifying you I am aware of this. My
> disagreement is not denying PHP malware exists, it is denying that your
> proposed change does anything to improve situations with code vulnerable
> to externally controlled includes. There may be a way to mitigate this
> problem, but I don't see how requiring that .php would be at the end of
> the filename would be it.
>
I'm presenting the fact that "PHP script embedded malware" exists
in the wild and malware vendors detect them as "PHP malware".
>
> > No other languages have such malware.
>
> Are you seriously claiming there is no malware written in languages
> besides PHP? It can not be, I must be misunderstanding what you mean here.
>
Malwares are written by many languages. It's the fact.
As far as I know, PHP is the only language that has this type of malware.
(Script embedded images) PHP is the only one malware vendors claims
it as "PHP malware". This is the fact.
> The reason why these has to detected as "PHP malware" is that there are
> > PHP programs vulnerable to script inclusion attacks.
>
> No, it's not the reason, at least not the main one. The reason is that:
> a. PHP is an easy language to write code in and is widely deployed
> b. Writing a remote control kit in PHP is easier than in C, etc. and
> there's more guarantee it would work on any random PHP host
> c. There are lots of vulnerable web hosts that have remote execution
> vulnerabilities and can be exploited
>
The reason is other languages are almost safe by default against script
inclusion attacks.
This RFC makes PHP safe by default just like other languages +
move_uploaded_file()
protection.
>
> > Leaving this as it is now would make people think "PHP is insecure than
> > other languages", "Wow, we have many PHP malware. We may be better
> > not to use PHP anymore".
>
> People that think that are illogical - the fact that somebody chose to
> write a remote control toolkit in PHP due to PHP'd high footprint on the
> web has absolutely nothing to do with PHP being less secure. It's like
> saying Ford cars are insecure because somebody robbed a bank and then
> drove away in a Ford car. We should pay absolutely zero attention to the
> opinion of people that are so confused, and instead educate them about
> the real situation.
>
> Of course, if people run no PHP server at all, PHP-driven remote control
> kits would not be useful. But if the server is vulnerable, there are
> many other backdoor kits.
>
People do not have to be exparts of developing softwares. Managers will
choose illogical choice.
> If "PHP malware" is found in a server, developers are force to check
> > their code. Or they have to ask costly code check to people like me,
> > even when PHP programs is safe. If this RFC is accepted, developers
> > can prove their PHP programs are safe without code check.
>
> I do not see how you change leads to anything like that.
>
1. Anti-virus detects "PHP malware"
2. Managers surprises possible attack (Server takeover)
3. Developers are forced to check their code, since current PHP has no
effective script inclusion attack prevention
With this RFC, developers can explain this type of attacks cannot be done
by PHP's feature. i.e. Exploit servers via script embedded images, etc
cannot
be done.
> This RFC benefits may not be obvious for people on this list, but this
> > RFC eliminates certain type of "PHP malware". PHP's script inclusion
>
> I can't think of any type of PHP malware that would be eliminated. At
> most, the malware injection protocols have to be slightly modified to
> work around initial hurdle of not being able to pass files with
> extension .php through move_upload_file(). With RCE vulnerability its
> trivial, with RFI one based on uploads it is a little harder, but only
> insignificantly - if I am not mistaken, in the last email I provided a
> workaround and it took me less than 5 minutes to come up with it,
> without being professional exploit writer.
>
Embedded PHP script uploads are prohibited by this RFC by default.
> is a toy for security researcher and attackers for a long time.
> > Let's take away the toy from them.
>
> It may be worth to take away the toy, but this change just moves the toy
> couple of centimeters aside. Given the BC break potential, I don't see
> much point.
PHP became as secure as other languages with respect to script inclusions.
by default. The issue here is "PHP is not being as secure as other language
with respect to script inclusion attacks". Statistics shows it. This is our
issue.
Users may shoot their own foot, this is not our issue.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
