CVE-2014-0185: PHP-FPM sockets unavailable after updating PHP

Reference: CVE-2014-0185

A few days ago, a security update to PHP was released that corrected the default permissions on the listening socket that PHP-FPM would create. If your PHP-FPM pool had a configuration like the one below, without an explicit owner/group/mode, it would default to user root, group root and mode 0666 (the snippet below is the default content of the php-fpm pool configuration).

;listen.owner = nobody
; = nobody
;listen.mode = 0666

The example above is in comments (note the lines starting with a semicolon), so wasn't active. That means the defaults of root/root/0666 were active. Sockets were created with the following permissions (read- and writable by all).

~# stat /var/run/php-fpm/pool.sock
Access: (0666/srw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)

The recent update to PHP (as of 5.3.38, 5.4.28 and 5.5.11) changes those default permissions, if not explicitly defined, to 0660. Meaning the socket is now only readable/writable by user root and group root. If your configuration depended on the "other" privileges being correct (meaning anyone can write to the socket and have it execute as the user php-fpm was executing as), your config will now break. These are the new default permissions.

~# stat /var/run/php-fpm/pool.sock
Access: (0660/srw-rw----)  Uid: (    0/    root)   Gid: (    0/    root)

So a more safe 0660 for everyone. Your Apache or Nginx logs can however trigger an error like this after the update, because the socket is unavailable to them.

HTTP/1.1 500 Internal Server Error

[error] [client] (13)Permission denied: FastCGI: failed to connect to server "/var/www/cgi-bin/http-socket.fcgi": connect() failed
[error] [client] FastCGI: incomplete headers (0 bytes) received from server "/var/www/cgi-bin/http-socket.fcgi"
... - - [x/x/2014:00:00:00 +0200] "HEAD / HTTP/1.1" 500 - "-"

There's no reason to change your Apache configurations or FastCGI configs. The fix is in applying the correct permissions in your PHP-FPM pool configuration. Uncomment the listen.* parameters and set them explicitly.

listen.owner = httpd = httpd
listen.mode = 0660

Remember: it's the webserver that is passing the request on to PHP-FPM, so the user that is running as the webserver needs read/write permissions on the Socket. In the case of Apache, that may be the 'httpd' or 'www-data' user, in the case of Nginx that'll be the 'nginx' user.

If you're struggling with permissions and need a quick resolution, you can change your PHP-FPM pool configuration (temporarily!!) back to the default permissions of earlier:

listen.mode = 0666

The new permissions and owner/group are only applied once you restart your PHP-FPM daemon.

If you're struggling with a PHP configuration no longer working after an PHP update, triggering HTTP 500 errors and throwing messages in your error logs about "failed to connect to server" (FastCGI), keep this in mind.

More info can be found on the PHP Sec Bug #67060: sapi/fpm: possible privilege escalation due to insecure default configuration page.

3 comments on “CVE-2014-0185: PHP-FPM sockets unavailable after updating PHP
  1. maltris says:

    German article on this from me:

    I also liked your english article on the german one. :)


  2. Mike says:

    I thought so! Newly provisioned server wasn’t working after giving it some fresh updates and I noticed the subtle different in the config files. Your article confirms it. Thanks for sharing.

  3. didifsx says:

    This post helped me so much, I was getting error 500 and this part “Uncomment the listen.* parameters and set them explicitly.” fixed it.


Leave a Reply

Your email address will not be published. Required fields are marked *



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Why ads?

I'm glad you made it to this blogpost. I hope it helps solve your problem. So why then do I show ads on the site? Writing content, testing it and making sure the layout isn't totally b0rked takes time. A lot of time. The ads are a way to pay back a small portion of that time.

And as you know running a site costs (a bit of) money: the domain name, webhosting, time spent writing and updating content, ... So if you like the content of this blog, consider disabling your AdBlocker for this domain. Thanks!

Looking for help?

Tired of fixing all these tech-problems yourself? We've got an excellent team at Nucleus, a top-class Belgian hosting provider, that can help you.

Discover our Managed Hosting, where skilled engineers manage your servers and keep them up-to-date, so you can focus on your core business. We use a variety of Configuration Management Systems such as Puppet to make sure every config is reviewed, unit-tested and guaranteed to be working.

Want to get in touch? Find me as @mattiasgeniar on Twitter or via the contact-page on this blog.