Hi! > 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. > 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. > 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 > 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. > 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. > 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. > 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. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
