Un problème d'isolation permet au worker PHP, qui exécute le code de l'application pour le compte du visiteur du site web, de prendre le contrôle de l'orchestrateur php-fpm qui, dans la configuration par défaut, s'exécute avec tous les droits sur le serveur. Cette faille permet une élévation de privilèges et est potentiellement exploitable à distance si un script PHP vulnérable est présent sur le serveur.

Mitigation évidente: ne pas faire tourner php-fpm avec les droits root. Dans une installation LEMP classique, on a:

• systemd qui doit orchestrer les services et s'exécute en root (inévitable)
• nginx qui reçoit les les requêtes web et les répartit, notamment vers php-fpm. Il fonctionne avec un processus maître qui fonctionne en root pour se mettre en écoute sur le port 443 et des workers, non privilégiés, qui traitent les requêtes
• php-fpm qui tourne sous root, reçoit les requêtes vers des scripts PHP de la part de nginx et les répartit vers des workers moins privilégiés.

Ça fait beaucoup trop de choses qui tournent avec les droits root. Systemd, c'est inévitable. Mais:

• php-fpm il n'y a aucune raison
• nginx la seule raison est de pouvoir écouter sur le port 443 (port privilégié). Mais on peut confier cette tâche à systemd et ainsi réduire les droits de nginx.

Une petite page sur freedesktop explique comment utiliser l'activation par socket pour nginx et php-fpm ce qui permet pour nginx de le lancer sans les privilèges root. Dans la configuration proposée, php-fpm est lancé avec l'utilisateur "nginx", ce qui est bien car ce n'est pas root, mais pas idéal car c'est le même utilisateur que nginx, donc ça expose les clés privées TLS a des scripts PHP compromis.

Avec cette configuration, si un script contient une faille, l'attaquant pourra:

• voler les identifiants et les données d'un autre utilisateur
• accéder à la base de données sans filtre ou à toute donnée à laquelle une application PHP sur le même serveur donne accès
• (potentiellement) modifier l'application

Mais il ne pourra pas:

• installer une application arbitraire sur le système
• accéder aux clés privées du système (SSH, TLS)
• rebondir vers d'autres systèmes via les comptes administrateurs

Le même type de failles est susceptible d'apparaître sur des serveurs logiciels d'autres langages (uwsgi ou gunicorn avec python, etc.), selon la configuration par défaut (droits root pour le processus maître ou non). La même mesure de protection s'applique.