Zend OPcache and PHP-FPM
There was some discussion regarding opcache and PHP-FPM in the Enhanced FPM support feature request. Comments for that feature request is now closed (admittedly the discussion of opcaching was probably a bit off topic).
Discussion about opcache and PHP-FPM brought up disclosure information in using Zend Opcache. None of that really seemed to get resolved and I'm not sure if it's really cPanel's place to resolve it, but I'm just wondering if there is a consensus on any of this.
Someone please correct me if I am wrong.
Am I right in saying that the only information disclosure in regards to Zend Opcache is that filenames and paths can be disclosed across different VirtualHosts?
If opcache.use_cwd is enabled, then information (i.e. PHP code, potentially database log in information) in duplicate filenames is not cached and shared across multiple VirtualHosts, correct? opcache.use_cwd is enabled by default.
By using opcache_get_status() filenames and paths to other cached files can be disclosed across multiple VirtualHosts. But if PHP-FPM is set up to use a chroot or if open_basedir is enabled and system()-like functions are disabled, then information in those files cannot be disclosed. Correct?
Would adding opcache_get_status() to the disable_functions list, basically stop this filename disclosure?
In the feature request discussion, I proposed using Xcache as an alternative to Zend Opcache for PHP 5.6 (and I suppose PHP 5.5). Xcache is not compatible with PHP 7 or PHP 7.1, so it's not an option for those. Xcache presents two configuration variables xcache.var_namespace_mode and xcache.var_namespace which should (I think?) resolve issues with information disclosure between multiple VirtualHosts (or users). Ideally, something similar to this would be added to Zend Opcache. Adding this functionality to Zend Opcache would seem to fall on the shoulders of PHP and not on cPanel. But is the above workaround enough of a solution to stop any harmful information disclosure?
-
Hello @sparek-3, If I understand correctly, the issue should have been addressed with internal case CPANEL-7016: CPANEL-7016: Chroot jailshell users when using jailshell or noshell Here's a quote from a related case that explains the expected behavior: GIVEN a php connection WHEN that user has /usr/local/cpanel/bin/jailshell OR /usr/local/cpanel/bin/noshell set as their shell THEN that pools PHP request should be executed chrooted inside of /home/virtfs/$username GIVEN a php request WHEN that user has any shell OTHER than /usr/local/cpanel/bin/jailshell OR /usr/local/cpanel/bin/noshell set THEN that pools PHP request should be executed without a chroot GIVEN a php request WHEN that user is using a jailed shell AND /home/virtfs is not set up for that user THEN jail mounts should be set up for that user
Could you let us know if this information helps? Thank you.0 -
That is all referring to chroot in php-fpm. That's... not really what this topic is about. This topic is about Zend Opcache and information disclosure. Chrooting doesn't really do anything in regards to that. All chrooting can do - if I'm understanding all of this correctly - is prevent someone from potentially reading other VirtualHost's files. Without disabling the opcache_*() functions, then VirtualHost#2 can potentially see what files exist on VirtualHost#1. I'm not sure if that amount of information disclosure is really all that condemning but it is an information disclosure hole. That's why I'm asking the question. I'm not sure on all of this. If you still don't understand what I'm talking about, let me know and I'll see if I can explain it better. If anybody else knows what I'm talking about and can think of another way of explaining it, please do so. I feel like I'm not explaining this good enough. It makes sense to me, but that doesn't mean that it makes sense to other people. 0 -
As a test, I enabled Opcache + FPM on a couple sites and loaded up an opcache control panel on one of them. I only saw files belonging to the user cached, so I'm assuming each pool has its own Opcache space. 0 -
What version of cPanel are you using? Did cPanel change the way PHP-FPM is run in cPanel 58 or cPanel 60? 0 -
I'm running 60 and have been sort of keeping up with the discussion over at the feature request thread. Nix what I said. There's some bug in the interface that shows FPM enabled when it's not, which I was coming on here to report, so the Opcache bleedover issue is still very much there. Pretty much the reason I haven't enabled FPM on any but a couple test sites. 0 -
I'm still running cPanel 56 and using the documented instructions for PHP-FPM (which I think cPanel says not to use now, but at the time who knew when cPanel would get around to integrating their own PHP-FPM setup... which I'm not entirely sure they have done yet). I don't really think there is going to be a way around this, unless you run a php-fpm master process for each user (which I don't think is feasible) or until Zend OpCache is patched to utilize something like Xcache's namespace, or you could use Xcache for PHP 5.6. The shared opcache space is always going to be there. But by disabling the opcache_*() functions you are at least limiting (perhaps closing?) the ability for end users to obtain information about other VirtualHosts on the server. At least that's my thoughts on it. Was hoping to get some other's thoughts/input/discussion. To see what API PHP is using for a specific VirtualHost, you can create a phpinfo page on the VirtualHost and then visit the VirtualHost's phpinfo page and note the Server API 0 -
I'm also curious whether those files can be manipulated while in cache. I don't care about the path information disclosure if the data isn't accessible. I used to use Xcache, but when I saw that the developer wasn't thrilled about a complete rewrite for PHP7, I dumped it. I reckon I'll try disabling those functions to see what happens, but the data would still be in the shared pool and the question "can it be gotten to by another user's compromised account?" remains. 0 -
I reckon I'll try disabling those functions to see what happens, but the data would still be in the shared pool and the question "can it be gotten to by another user's compromised account?" remains.
This is what I'm wondering to. The data is still there in the "shared pool" but can the actual data be accessed by other VirtualHosts? All disabling the opcache_*() functions is doing is preventing or making it more difficult for other users to see that data. And as you say there's really nothing inherently insecure about disclosing files and file paths as long as the code in those files is not disclosed. Sure, VirtualHost#2 can find out that VirtualHost#1 has a file at /home/user1/public_html/secret.php but as long as they can't what's in that file, it's not a huge deal. I do know that if you disable opcache.use_cwd then data can be accessed across different VirtualHosts. There's information on this in PHP's bug report - PHP :: Bug #67481 :: Opcache uses wrong file from cache - which is slightly dated and it's worth mentioning that opcache.use_cwd is enabled by default, so the best I can tell that is not an issue.0 -
I did a little googling and think that since the opcache functions in PHP are only for maintenance purposes (listing/flushing/etc), I'm inclined to say the info in cache will not be accessible unless there's some way to fool opcache into a collision, sort of like the bug you linked. Perhaps someone well-versed in PHP could chime-in. I'm filling out a form at Zend to see if they respond. 0 -
Not a peep from Zend and silent here, so perhaps there's no case to be made for worry and my last post's theory is correct. 0 -
Or perhaps nobody is aware that this is an issue or a potential issue. I'm somewhat inclined to believe that the chance of any data compromise is very low. The file path information leak is somewhat concerning, but as you say, it's not really a dealbreaker and from what I can tell that can be mitigated by blocking access to the opcache_*() functions. Zend may be seeing PHP access as a single-user platform instead of the multi-user platform that shared hosting is. In a single-user environment and information or data disclosure wouldn't seem to be a bit deal, because if everything is owned by that one user, then that one user has access to everything already. 0 -
Hello, To bring up a comment from earlier in the thread, yes, there's a difference in how PHP-FPM is implemented in cPanel version 60. The previously documented method of enabling PHP-FPM is no longer supported, and administrators are advised to revert any steps they took to enable FPM at that time. Here's the document regarding PHP-FPM support in cPanel version 60: PHP-FPM and EasyApache 4 - Documentation - cPanel Documentation Regarding the topic here, could you provide us with step-by-step instructions on how to reproduce this issue so we can determine if it's by design or if an internal case is necessary? Thank you. 0 -
It's not really a cPanel issue, it's a Zend or PHP issue. Create two VirtualHosts setup with different PHP-FPM pools (we'll call them example1.tld and example2.tld). With different user pools (i.e. user1 and user2). Create a PHP file (i.e. "Hello World") on example1.tld, and visit it, i.e. [plain]http://example1.tld/hello.php[/plain] [php] [/php] Now on example2.tld create a cache.php file: [php]
[/php] Now visit [plain]http://example2.tld/cache.php[/plain] Note how example2.tld can learn of files that exist on example1.tld[scripts] => Array ( [/home/user1/public_html/hello.php] => Array ( [full_path] => /home/user1/public_html/hello.php
This may be making a mountain out of a molehill. Does it disclose anything important? Not really. At least that I know of. But it does disclose path information. Since example2.tld can see the files that have been accessed on example1.tld, is it possible for example2.tld to read the contents of that cached data from example1.tld? If so, then that's a concern. How does this rate on disturbing people? I don't know. But something to think about if you are using or want to use Zend OpCache any shared hosting environment.0 -
Hello, Here's a quote from a recent internal case that you may find helpful: Opcache w/FPM is secure. OPCache uses shared memory to cache compiled PHP "opcode" between HTTP requests for reuse. A single shared memory object is opened and initialized in a parent process, and child processes inherit its file descriptor. Due to this design, OPCache is intended for use with a SAPI with a persistent parent process, for example php-fpm with its master process, or apache2handler where initialization occurs in the Apache parent process.
I've been unable to reproduce the example from the previous response on cPanel version 60 with PHP 7, Zend Opcache, and PHP-FPM. The cache.php file in the example you provided doesn't list the file name from the other account. What specific steps are you taking to enable PHP-FPM and Zend Opcache on the system so we can try to replicate the environment you are using? Thank you.0 -
No time to play, right now, but in my case I just enabled FPM on a domain with a Wordpress install, then used an Opcache manager on a different account (also on FPM) to see the list of cached files on the Wordpress account. 0 -
No time to play, right now, but in my case I just enabled FPM on a domain with a Wordpress install, then used an Opcache manager on a different account (also on FPM) to see the list of cached files on the Wordpress account.
Could you verify if the system uses the supported PHP-FPM implementation in cPanel version 60, and OPcache was installed via EasyApache 4? Thank you.0 -
Could you verify if the system uses the supported PHP-FPM implementation in cPanel version 60, and OPcache was installed via EasyApache 4? Thank you.
Yup. It's a standard install with PHP7-FPM and Opcache done through the GUI. Manually setting up FPM looked like too much of a pain. Here's Opcache from a Wordpress install listing another user's Magento files. As previously stated, I don't really care if users can see this, just wondered if there was some way for them to access the files. My opinion is "no", but what do I know?0 -
Hello @RWH Tech, Would you mind opening a support ticket using the link in my signature so we can see that in action and verify how everything is configured on that system to determine if the behavior is by design or requires attention? Thank you. 0 -
Hello @RWH Tech, Would you mind opening a support ticket using the link in my signature so we can see that in action and verify how everything is configured on that system to determine if the behavior is by design or requires attention? Thank you.
I've created ticket 8010331 so you guys can look around!0 -
Andrew took a look and didn't add any new info to what we know, save for a suggestion to use file caching set on ~/opcache, which I reckon is an option, albeit a slow one. He didn't mention anything about my config, and it is stock(save for Apache with HTTP2), so all checks out there. 0 -
Hello @RWH Tech, I checked with our EasyApache 4 development team and have confirmed this is due to the nature of how Opcache works. It's not recommended for use on a shared hosting environment. The top answer on the following URL is a useful resource that explains why: Two separate PHP-FPM sites seem to be using the same code? Thank you. 0 -
There is a patch for opcache file collisions in a chroot'd environment PHP :: Request #69090 :: add prefix/xor to cache keys/check permissions or separate caches I can confirm that it does solve the collision problems when using opcache in a chroot'd environment. Is this a patch that cPanel needs to include in their PHP offering? Or do you think PHP will include it in later releases (Note the patch was first created on November 15th, 5 days after PHP 5.6.28 was released). This bug only seems to affect opcache in a chroot'd environment. I doubt many cPanel users are using php-fpm chroots (I doubt many cPanel users are using php-fpm period). All that being said, I'm left to agree with @cPanelMichael and the people from ServerFault that using OpCache in any shared hosting environment isn't recommended. The new question is, is there a compiled byte-code optimizer that is recommended for shared hosting environments? In the original post to this thread I mentioned Xcache as being a possible replacement, given it's xcache.var_namespace_mode and xcache.var_namespace variables. But Xcache only works up to PHP 5.6 and I don't think there are any plans to continue it with PHP 7.0 or PHP 7.1. It's also important to note that most people have been or probably still are using suPHP as their PHP Handler. No compiled byte-code optimizer works with suPHP (at least that I am aware of). So the lack of OpCache, Xcache, or any compiled byte-code optimizer probably isn't much of a detriment as one might think. 0 -
There is a patch for opcache file collisions in a chroot'd environment I can confirm that it does solve the collision problems when using opcache in a chroot'd environment. Is this a patch that cPanel needs to include in their PHP offering? Or do you think PHP will include it in later releases (Note the patch was first created on November 15th, 5 days after PHP 5.6.28 was released). This bug only seems to affect opcache in a chroot'd environment. I doubt many cPanel users are using php-fpm chroots (I doubt many cPanel users are using php-fpm period).
A resolution for that particular PHP bug is included with the latest PHP versions: You can search for "69090" on the above links to see it's inclusion. Those versions are not yet included with EA4, as the most recent PHP versions must go through our own testing and build process before publication. You can monitor the EA4 change log to see when updated PHP versions are included with EA4.0
Please sign in to leave a comment.
Comments
23 comments