php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74182 Unsafe default for opcache.validate_permission
Submitted: 2017-02-28 15:23 UTC Modified: 2017-02-28 16:42 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: michael at orlitzky dot com Assigned:
Status: Open Package: opcache
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2017-02-28 15:23 UTC] michael at orlitzky dot com
Description:
------------
The opcache.validate_permission setting was introduced to fix a vulnerability (now CVE-2015-8994) in shared hosting environments. However, it defaults to "0", meaning it's off.

The performance impact of the additional check should not be cataclysmic, and shared hosting is almost synonymous with PHP. As a result, I think the default should be opcache.validate_permission=1.

Reference:

http://www.openwall.com/lists/oss-security/2017/02/27/4



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-02-28 16:30 UTC] spam2 at rhsoft dot net
> Many common shared hosting configurations change EUID in child 
> processes to enforce privilege separation among hosted users. 
> In these scenarios, default Zend OpCache behavior defeats 
> script file permissions by sharing
> a single SHM cache among all child PHP processes

frankly i don't get the whole problem and list discussion

if you want user separation you are normally supposed to start seperate master instances be it FPM-ppols or sepearted httpd-instances in case of mod_php and the childprocesses of each pool are supposed to share the SHM cache

without sharing the cache between children you end in a desaster as realpath_cache does for a decade now: https://bugs.php.net/bug.php?id=73888 (not enough that you need to patch the php source that it get enabled at all wehn using open_basedir while you are sure that all link/symlink functions are forbidden and so there is no security problem)
 [2017-02-28 16:41 UTC] spam2 at rhsoft dot net
> opcache.validate_permission (default "0")
> Leads OPcache to check file readability on each access 
> to cached file. This directive should be enabled in shared 
> hosting environment, when few users (PHP-FPM pools) 
> reuse the common OPcache shared memory

"The performance impact of the additional check should not be cataclysmic"

no - it is not - it defeats "opcache.validate_timestamps" with a high "opcache.revalidate_freq" while the whole purpose is to minimize disk operations as much as possible

enable that by default just because there could be someone with a not well thought configuration is not justified, anyways, thans for the pointer so that i put "opcache.validate_permission = 0" in configurations if someone later decides to change the default
 [2017-02-28 16:42 UTC] michael at orlitzky dot com
> if you want user separation you are normally supposed to
> start seperate master instances be it FPM-ppols or sepearted
> httpd-instances in case of mod_php and the childprocesses of
> each pool are supposed to share the SHM cache

Here's how this affects us: we have a separate system user for each website. In Apache, mpm_itk is used to run each virtual host as that dedicated user, sharing one mod_php. The end result is that the PHP code runs as a dedicated user on each website that uses PHP. However, there is one global cache that all users have access to.

No one is suggesting that the global cache be eliminated. Only that filesystem permissions should not be bypassed when the cache is turned on.
 [2017-02-28 16:53 UTC] spam2 at rhsoft dot net
well, and i know setups where you have undret httpd instances with mod_php, each running as seperate user and the additional stat call is just a surprising increase in IO operations when teh default changes

would you set "open_basedir" in your setup with the shared mod_php for each virtual host one could not bypass that way because openbase_dir is validated within opcache and don't need disk IO to work

without you rely completly in filesystem permsissions and i doubt thats eonugh in the real world where users/customers careless set 0666 or even 0777 on their uploaded scripts
 [2017-02-28 17:06 UTC] michael at orlitzky dot com
> would you set "open_basedir" in your setup with the shared mod_php
> for each virtual host one could not bypass that way because
> openbase_dir is validated within opcache and don't need disk IO
> to work

I've already done that on our servers, but I've also already set opcache.validate_permission=1. There's no doubt that somebody who knows what he's doing can set things up safely. The only question is whether the default configuration should be a little bit faster or a little bit more secure.

My take is that everyone needs their installation to be secure, but not everyone needs the utmost performance. The sites where things truly need to be fast will have administrators that know what they're doing and can enable optimizations like opcache.validate_permission=0. On the other hand, almost nobody knows about the setting, so the nearly-everybody who would prefer the secure mode will not have it set correctly.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Mon Nov 23 20:01:23 2020 UTC