Req #69090 [Com]: add prefix/xor to cache keys/check permissions or separate caches

From: Date: Wed, 04 Nov 2015 09:14:08 +0000
Subject: Req #69090 [Com]: add prefix/xor to cache keys/check permissions or separate caches
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-197009@lists.php.net to get a copy of this message 
Edit report at https://bugs.php.net/bug.php?id=69090&edit=1

 ID:                 69090
 Comment by:         michal_micko at centrum dot cz
 Reported by:        simon at ikanobori dot jp
 Summary:            add prefix/xor to cache keys/check permissions or
                     separate caches
 Status:             Analyzed
 Type:               Feature/Change Request
 Package:            opcache
 Operating System:   linux/debian
 PHP Version:        5.6.5
 Block user comment: N
 Private report:     N

 New Comment:

important note to the previous example:
---------------------------------------
PHP is running as Apache module


Previous Comments:
------------------------------------------------------------------------
[2015-11-03 22:42:07] michal_micko at centrum dot cz

I replicate this problem with two VirtualHosts (using open_basedir).

OS: Debian 8.1
php -v
PHP 5.6.14-0+deb8u1 (cli) (built: Oct  4 2015 16:13:10) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with XCache v3.2.0, Copyright (c) 2005-2014, by mOo
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans
    with XCache Optimizer v3.2.0, Copyright (c) 2005-2014, by mOo
    with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo
    with XCache Coverager v3.2.0, Copyright (c) 2005-2014, by mOo

Apache: 2.4.10

VirtualHosts:
-------------
cat 050-opcache-fail.conf 
<VirtualHost *:80>
    ServerName app1
    DocumentRoot /var/www/app1/web
    php_admin_value open_basedir /var/www/app1
    <Directory /var/www/app1/web>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        #Order allow,deny
        #Allow from All
        Require all granted
    </Directory>
</VirtualHost>

<VirtualHost *:80>
    ServerName app2
    DocumentRoot /var/www/app2/web
    php_admin_value open_basedir /var/www/app2
    <Directory /var/www/app2/web>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        #Order allow,deny
        #Allow from All
        Require all granted
    </Directory>
</VirtualHost>

Example - PHP apps - typical using with composer (dummy):
---------------------------------------------------------
apps directory structures: /var/www/

app1
  vendor
    third
      party
        lib.php
    autoload.php
  web
    index.php

app2
  vendor
    third
      party
        lib.php
    autoload.php
  web
    index.php


web/index.php (same app1 and app2):
-----------------------------------
<?php
require_once __DIR__ . '/../vendor/autoload.php';

echo (new third\party\lib())->getName();
?>


vendor/autoload.php (same app1 and app2):
-----------------------------------------
<?php
require_once __DIR__ . '/third/party/lib.php';
?>


vendor/third/party/lib.php (app1):
----------------------------------
<?php
namespace third\party;

class lib
{
    public function getName()
    {
        return 'good library';
    }
}
?>


vendor/third/party/lib.php (app2):
----------------------------------
<?php
namespace third\party;

class lib
{
    public function getName()
    {
        return 'bad hacked library';
    }
}
?>


Security issue:
---------------
It would be a problem in webhostings. After web server restart just run bad app2 as first.



Workaround:
-----------
opcache.optimization_level=0

------------------------------------------------------------------------
[2015-09-24 18:32:19] toni at lygon dot net

I can replicate this with php5-fpm 5.5.9+dfsg-1ubuntu4.11.

I baffled how a huge security / usability problem like this can exist, yet nobody gives a poop about
it.
We've got a server with multiple sites chrooted using the same directory structure inside the
chrooted /.
Obviously this causes fatal problems as there are conflicts, like index.php in those hosts causing
it to randomly load from any of those.

Because of this, opcache can not be used as we can't change the directory structure.

Someone, please investigate this!

------------------------------------------------------------------------
[2015-07-26 17:10:12] thesparkdevelopment at gmail dot com

noescape at centrum dot sk:

I think open_basedir is useless in chroot

------------------------------------------------------------------------
[2015-07-16 19:09:25] noescape at centrum dot sk

I cannot seem to replicate this... But I got open basedir enabled. Can somebody verify that open
basedir solve it?

------------------------------------------------------------------------
[2015-06-14 09:04:02] thesparkdevelopment at gmail dot com

4 month for critical fix... it's bad...

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=69090


--
Edit this bug report at https://bugs.php.net/bug.php?id=69090&edit=1

Thread (38 messages)

« previous php.bugs (#197009) next »