Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain coydogsoftware.net designates 162.246.56.219 as permitted sender)
Date: Fri, 11 Nov 2016 07:03:29 -0600
To: Dmitry Stogov <dmitry@zend.com>
Cc: "rasmus@lerdorf.com" <rasmus@lerdorf.com>,
	"internals@lists.php.net" <internals@lists.php.net>,
	"Anatol Belski (ab@php.net)" <ab@php.net>,
	Zeev Suraski <zeev@zend.com>
Message-ID: <20161111130329.GA22968@sliver.coydogsoftware.net>
References: <MWHPR02MB247797DCC52957382A6E120BBFBB0@MWHPR02MB2477.namprd02.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MWHPR02MB247797DCC52957382A6E120BBFBB0@MWHPR02MB2477.namprd02.prod.outlook.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [PATCH] opcache bug #69090, prepend user identifier to keys
From: php-dev@coydogsoftware.net

Dmitry,

Thank you for taking the time to answer my questions. Time allowing,
I'll be taking a closer look at the code this weekend. I do have a
couple of quick comments, see below:

On Fri, Nov 11, 2016 at 07:31:03AM +0000, Dmitry Stogov wrote:
> On Nov 10, 2016 5:10 PM, php-dev@coydogsoftware.net wrote:
> >
> > Can you confirm that you see the permissions bypass problem? I've seen
> > the chroot filename collision problem acknowledged in the bugtracker and
> > in old php-internals posts, but I've seen nobody from the PHP Project
> > explicitly acknowledge the permissions bypass vulnerability. If my
> > meaning isn't clear I can provide proof of concept off-list. The
> > permissions bypass affects both apache2handler (even with mod_ruid2) and
> > FPM (even with user pools).
> 
> I didn't see the problem in real life, but it's clear, that serving of
> few chroot environments using the same cache may lead to duplicate
> keys. FPM with separate pools shouldn't be affected.

FPM with separate user pools under a single master is affected by the
permissions bypass issue. To avoid the issue, separate user pools isn't
sufficient; you would need separate FPM master daemons.

Many users read about the ability to run separate pools with separate
users under a single master and think this provides adequate user
separation: 
http://php.net/manual/en/install.fpm.configuration.php

But when OPCache is enabled, the user pools under a single master all
share a common cache, with disastrous results if a single user is
compromised.

Unfortunately this is the way the popular shared hosting control panels
have started implementing FPM: with a single master.

Was "single master, multiple pools with separate users" not intended for
a shared hosting environment? If not, what is the point of the 'user'
and 'chroot' directives? Were shared hosts using FPM always expected to
use separate FPM master daemons? If so, the documentation might be more
explicit IMHO (I'd be willing to put in some work here if you feel a
documentation fix is what's needed).

> > But again I should stress that *chroot filename collisions are not the
> > only bad behavior here.* They're not the bug I'm most concerned with.
> 
> Do you talk about executing "unreadable" PHP scripts of different
> users?  I think, the proper way to fix this, whould executing access()
> check on each cached script access (this might be enabled/disabled
> through php.ini)

Yes! This is exactly my concern. And you're absolutely right, a check of
access() at script compile time is a better solution than my patch. I
think it should be the default behavior though.

I'm starting to think I should have opened a separate bug for the
permissions bypass issue and the chroot filename collision; in the
bug tracker users were already lumping these issues together but they're
really separate concerns.

Off-list I'm going to send you a proof of concept script which
demonstrates the problem with a typical FPM/OPCache deployment in a
shared environment.

-php-dev at coydogsoftware dot net