Security Misconfiguration Vulnerability in various Doctrine projects
We are releasing new versions of Doctrine Cache, Annotations, ORM and MongoDB ODM today that fix a security misconfiguration vulnerability. This vulnerability was assigned CVE-2015-5723. It requires an attacker to have direct access to a user of the server to be exploitable. We consider exploitability to be low to medium.
Exploiting this vulnerability can allow attackers to perform local arbitrary code execution with privileges of other users (privilege escalation).
You are only affected by this vulnerability, if your application runs with a umask of 0.
- Annotations to 1.2.7
- Cache to 1.4.2 or 1.3.2
- Common to 2.5.1 or 2.4.3
- ORM to 2.5.1 or 2.4.8
- MongoDB ODM to 1.0.2
- MongoDB ODM Bundle to 3.0.1
If you want to check the fix or apply patch manually, we provide a Gist with all patches.
If you cannot upgrade, see our notes below how to mitigate the problem without having to patch the code.
We want to thank Ryan Lane for finding the vulnerability, Jonathan Eskew from the AWS team to pass this security vulnerability to us and Anthony Ferrara for helping us discuss and find solutions to the problem.
Doctrine uses different kinds of caches and some of them read the cached
include to make use of APC or Opcache. In
case of proxy generation we actually need to execute the code to make a
new auto-generated class part of the code-base.
Doctrine always uses
mkdir($cacheDirectory, 0777); on many of those
caches directories. If your application is running with
allows an attacker to write arbitrary code into the cache directory
which can be executed with the user privileges of the webserver.
Running your application with
umask(0) is not generally a good idea,
but is sometimes recommended as simple solution to solve filesystem
access problems when a console and a web user both write to a common
cache directory. In combination with a cache that executes the cache
entries as code, this can allow local arbitrary code execution.
The patches released today change all caches that execute code to always
use a default mask of
0775 instead of
- In case of Cache and Annotations we solve this by implementing a
userland configurable umask that defaults to
0002. We apply this to every mkdir and chmod so that you can reconfigure to another mask if you must.
- In all the other cases its a hardcoded change to
0775for directories and
We are aware that if you depend on
umask(0), this is a very
inconvenient change, because your code will break when different users
write to the same cache directory.
We feel it is not safe to make developers and operations responsible to know how to secure our cache implementations. They are often third party libraries to other open-source systems, we want them to be safe no matter how users configure their system.
Am I vulnerable?
Your application must run with
umask(0) for this vulnerability to be
exploitable. This must not necessarily be an explicit call to the PHP
function, it can also happen if you misconfigured your shell or
webserver to run with umask 0 by default.
You can easily check this by calling
echo umask(); from both the shell
and your webserver. It will return 0, if you are potentially vulnerable.
Second, you must be using using Doctrine with the Annotations FileCache or the PhpFileCache Cache implementation or one of the ORM or ODM ProxyGenerators. Of course this vulnerability can also be present in any other library or your own application, when you dynamically generate PHP code into a directory with world writable permissions.
Do you provide fixes for all branches of all affected components?
No, fixes are only applied to the most recent versions of Doctrine components.
If you are running older components and don't want to or cannot upgrade, you should look into the sections about immediate and proper fixes below, that show solutions that don't require upgrading your code.
If your system and application are correctly setup, it is also likely that you are not vulnerable. See the next section for information about that.
Is there an immediate fix when I can't upgrade?
Yes, as an immediate fix just make sure that your application runs with
a non-zero umask all the time. Call
umask(umask() | 0002); early in
your code to prevent PHP from ever creating world writeable files and
Warning: It can break your application if it relies on running with
This is not sufficient though, because the call to umask is not thread
safe and a call to this function later in the code can reset the umask
for all requests currently running. That means you must identify all
code that calls
umask(0); and change it.
When you are unsure if your generated cache is clean, you can regenerate all files after you have changed the umask of your application.
Is there a proper fix or security best-practive to avoid this issue?
Yes, the best way to fix this problem is to always execute PHP code for
a single application with the same user, independent of being called
from the webserver, php-fpm or the shell. In this case you can always
create directories with the default permissions of
0775 and files with
<?php // safety measure to overrule webserver or shell misconfiguration umask(umask() | 0002); mkdir("/some/directory", 0775); file_put_contents("/some/directory/file", "data"); chmod("/some/directory/file", 0664);
On most linux distributions it is possible to execute cronjobs or
supervisord jobs with the
apache users that the
webserver runs with.
Another way would be to use more advanced permission systems in Linux
chmod +a or
setfacl, both of which are not available on all
Isn't everyone just using 0777/0666 everywhere?
Yes, this practice is extremely wide-spread in many projects. This is why we think it is very important to make sure your application runs with a proper umask.
However, in our case the potential vulnerability is more severe than
usual, because we use
require/include to execute the written cache
files, which can allow an attacker with access to a local user the
possibility for executing arbitrary code with the webservers user.
Code that is reading the generted/cache files using
fopen/file_get_contents could "only" be poisoned with invalid or wrong
data by an attacker. This is severe by itself, but does not allow
arbitrary code execution.
We want users of Doctrine to be safe by default, so we are changing this even if it will cause inconveniences.
We have also notified as many OSS projects of this beforehand, mainly through PHP-FIG, because of the wide-spread practice. Several of them are preparing security releases for their libraries as well.
Again, the nature of this issue is mostly remedied by not running with umask of zero, so make sure this is the case for your applications.
If you have questions you can signup to the Doctrine User
ask there or join
#doctrine IRC Channel on Freenode.