A flaw was found in PHP versions 5.6 and 7.x. After changing UID and GID, PHP-FPM sets pool worker processes to be dumpable. This allows a local user with the same UID and GID to attach to the PHP-FPM workers and gain access to any restricted resources that are not supposed to be allowed. As a result sensitive configuration data for other accounts can be accessed directly in the PHP worker process's memory. References: https://bugs.php.net/bug.php?id=75605 Patch: https://bugs.php.net/patch-display.php?bug_id=75605&patch=bug75605-patch-for-5-6&revision=latest https://bugs.php.net/patch-display.php?bug_id=75605&patch=bug75605-patch-for-7-0&revision=latest
Created php tracking bugs for this issue: Affects: fedora-all [bug 1563860]
Statement: Red Hat Product Security has rated this issue as having a security impact of Low, and a future update may address this flaw.
PHP's opcache contains sensitive shared memory used to cache php bytecode. This memory pool is shared by children of the php-fpm process (workers) who are spawned by root then change uid/guid to another user. When this happens, the dumpable process flag gets set back to /proc/sys/fs/suid_dumpable (0). php-fpm needs to be able to ptrace these processes for functionality related reasons. However, as php-fpm already runs as root, setting this flag is redundant and has the side-effect of allowing lower privileged users to dump the worker processes which can contain sensitive memory. For example, if a php-fpm worker spawned as apache:apache, the apache user could then ptrace the process and get access to other workers memory via the opcache. Exploiting this would require already being on the system -- shared hosting seems like the most obvious case. Here's a vulnerable php-fpm with a worker running as apache: bash-4.2$ whoami apache bash-4.2$ ps PID TTY TIME CMD 27985 pts/0 00:00:00 php-fpm 27986 pts/0 00:00:00 php-fpm 27987 pts/0 00:00:00 php-fpm 27988 pts/0 00:00:00 php-fpm 27989 pts/0 00:00:00 php-fpm 27993 pts/0 00:00:00 bash 27995 pts/0 00:00:00 ps bash-4.2$ gcore 27989 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f3b0ecdcb40 in __accept_nocancel () from /lib64/libc.so.6 Saved corefile core.27989 Here's a run after I patched it as user nobody: bash-4.2$ whoami nobody bash-4.2$ ps PID TTY TIME CMD 27821 pts/1 00:00:00 php-fpm 27822 pts/1 00:00:00 php-fpm 27831 pts/1 00:00:00 bash 27842 pts/1 00:00:00 ps bash-4.2$ gcore 27822 ptrace: Operation not permitted. You can't do that without a process to debug. The program is not being run. gcore: failed to create core.27822 So before we can dump as the user, after we cannot.
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Via RHSA-2019:2519 https://access.redhat.com/errata/RHSA-2019:2519
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2018-10545