New patch, attached to bug report, should fix both problems. I'm going to commit it tomorrow, if no objections.
Thanks. Dmitry. ________________________________ From: Dmitry Stogov <dmi...@zend.com> Sent: Tuesday, November 15, 2016 2:41:47 PM To: php-...@coydogsoftware.net Cc: ras...@lerdorf.com; internals@lists.php.net; Anatol Belski (a...@php.net); Zeev Suraski; Nikita Popov; Julien Pauli; Joe Watkins Subject: [PHP-DEV] Re: [PATCH] opcache bug #69090, prepend user identifier to keys hi, I've solved one of the problems described at https://bugs.php.net/bug.php?id=69090 The patch and explanation are attached to bug report. Please, review. Julien, Anatol, Joe, are you OK to commit this into 5.6 and above? I'm going to think about the second problem. Thanks. Dmitry. ________________________________ From: php-...@coydogsoftware.net <php-...@coydogsoftware.net> Sent: Friday, November 11, 2016 4:03:29 PM To: Dmitry Stogov Cc: ras...@lerdorf.com; internals@lists.php.net; Anatol Belski (a...@php.net); Zeev Suraski Subject: Re: [PATCH] opcache bug #69090, prepend user identifier to keys 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-...@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
