Hi Stas, On Thu, Feb 26, 2015 at 10:48 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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? > One additional comment on this. The issue here is the same as safe_mode. It's "caller"and "callee" responsibility issue. One of the reason why safe mode design was failed is it made "callee" responsibility that making sure safe operation even if there are conditions to be secure. allow_url_include is the same. It made "callee" responsibility to be secure. As your example illustrates, it fails. Defense in depth can fail if it isn't designed carefully. "Caller" must have responsibility when there are conditions to be secure. Or "callee" must separate entry point/settings to cover all conditions. Both allow_url_include and safe mode have the same design problem. These are broken in the first place. Anyway, although it is related, this is different security issue to be fixed and I hope you agree to fix it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
