Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1563858 - (CVE-2018-10545) CVE-2018-10545 php: Dumpable FPM child processes allow bypassing opcache access controls
CVE-2018-10545 php: Dumpable FPM child processes allow bypassing opcache acce...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20171130,reported=2...
: Security
Depends On: 1563859 1598571 1598572 1598573 1563860
Blocks: 1563865
  Show dependency treegraph
 
Reported: 2018-04-04 19:09 EDT by Laura Pardo
Modified: 2018-10-25 11:41 EDT (History)
7 users (show)

See Also:
Fixed In Version: php 5.6.35, php 7.0.29, php 7.1.16, php 7.2.4
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laura Pardo 2018-04-04 19:09:18 EDT
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
Comment 1 Laura Pardo 2018-04-04 19:10:13 EDT
Created php tracking bugs for this issue:

Affects: fedora-all [bug 1563860]
Comment 9 Scott Gayou 2018-07-05 16:25:53 EDT
Statement:

Red Hat Product Security has rated this issue as having a security impact of Low, and a future update may address this flaw.
Comment 10 Scott Gayou 2018-07-06 12:26:34 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.