Hi Stas, I think you mean I ignored this. Let's discuss it.
============================================ > They'd need to upload with a matching file type. Instead of any file Not sure what you mean by that. phar can read tars, etc. AFAIK, can't it? Also, phar archive has no requirement of being named something.phar, afaik can be also named cuteponies.gif. E.g., I just did this: 1. Created file chump.php: <?php include $argv[1]; This is an idealized vulnerable script. 2. Created file pwnd.php <?php echo "pwnd!"; This is an idealized exploit. 3. Put it into an archive: tar cvzf cuteponies.gif pwnd.php 4. Run this: php -dallow_url_include=0 chump.php phar://cuteponies.gif/pwnd.php The output is: pwnd! I'm not sure how this measure would protect from such scenario. Am I missing something here? ============================================ This can be prevented by restricting phar archive name or forbid all URI name at all. The latter is better choice. The root cause of this is the way "allow_url_include" is implemented. "allow_url_include=Off" should disallow any type of URI include in the first place. As you know, PHP can have custom loaders that use URI form. Therefore, any kinds of custom loaders can be enabled by modules. It's a nightmare for security standpoint. There is design problem obviously. The reason why phar:// is allowed is that "allow_url_include" is not INI_ALL. http://php.net/manual/en/filesystem.configuration.php Script cannot change the setting, therefore special phar:// is needed to be allowed unconditionally. I would say INI_SYSTEM for allow_url_include is false sense of security. It introduced security issue like you've mentioned. To resolve issues with custom loaders, we need to change the design. This kind of *design mistake* is better to be fixed anyway. I don't mind to write another RFC and implement it. What do you think? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net On Thu, Feb 26, 2015 at 8:26 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > > Padraic, I'm not really interested in another prolonged discussion, > especially where my arguments are ignored or misconstrued and then > dismissed. I have explained my opinion, if somebody has questions about > the substance of my arguments or need me to clarify my points, rather > than flat-out denial of what I am saying, they know where to find me. I > think this RFC is bad. You think it's excellent. I tried to explain my > point to you, judging by your responses, I failed to convey my meaning. > I am probably bad at this, but I'm not going to become better by > repeating the same over and over. > I don't see what else I can do here - if majority of people would agree > with you, we'll have another bad security feature in PHP, and will have > to deal with it for the next decade, just as we had to suffer the safe > mode problems. I hope this will not happen, but I really don't see what > else I can say, provided that what I already said - including > demonstrating trivial workarounds that allow to circumvent this feature > with extreme ease - had no effect. > > > Is there some sort of meter on Internals where, in the red, there is > > an obligation to fill it back up with FUD, logical fallacies and the > > occasional fib? > > I also would really like for you to stop accusing me of lying. I may be > mistaken, and I am sure I have been many times, but everything I write > here is a product of careful consideration and thought, and aimed at > making PHP better. The next instance you do this, I'm not going to > reply, I'm just going to delete all following communications from you, > from that point, forever. I can handle very spirited technical > disagreement, I'm not new on the internet, but I do not see what use > would be for me to spend my time on being insulted. There are a lot of > more productive uses of my time. If there's no mutual respect here, then > the chance of productive cooperation is nil. I hope we can hold > respectful discussion, even when disagreeing. But if not, then I won't > participate in any other kind. > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
