Comme je vous le promettais hier je vous parle aujourd’hui des enjeux et des dangers que j’ai découverts pour le safe_mode (ou plutôt sa désactivation) utilisé avec le panel de gestion de serveur DTC.
Tout d’abord, petit retour rapide sur le fonctionnement de DTC :
DTC crée un utilisateur « dtc » et un groupe « dtcgrp » avec lesquels il fait la plupart de ce qu’il a à faire. Ainsi le ftp est géré par l’utilisateur DTC, les connexions en SSH également (mais justement il y a de sacrés bugs là-dessus), les connexions imap, smtp, etc… etc… et également les connexions HTTP, et donc les lancements d’Apache2 !
Concrètement, DTC est fait pour gérer un serveur dédié et donc proposer divers hébergements à divers sites.
Il crée toute une arborescence à laquelle on adhère ou non mais qui a le mérite d’être relativement claire et facile à utiliser et retenir.
Tous les fichiers de tous les sites appartiennent ainsi à un seul et unique couple user/groupe : dtc/dtcgrp.
DTC utilise énormément le principe plus ou moins bon des chroot pour lancer ses scripts de manière à les « endiguer » et qu’ils n’aillent pas faire n’importe quoi, particulièrement sur les fichiers appartenant à DTC sur le serveur.
Cependant DTC n’a pas prévu une chose… c’est l’utilisation de la commande shell_exec() de PHP (PHP 5 notamment, je ne sais pas pour le 4).
Par défaut, le safe_mode étant activé avec PHP, la commande shell_exec est quasiment inutilisable.
Cependant, si par malheur vous désactiver le safe_mode sur un domaine particulier… catastrophe ! Vous venez d’autoriser la personne qui s’occupe du site de ce domaine, à faire n’importe quoi sur le serveur (enfin sauf tâches d’administration (root) ).
Non seulement parce-qu’elle peut maintenant utiliser shell_exec() pour effectuer des actions au niveau de l’utilisateur dtc, mais surtout parce-que, même si certaines commandes sont bridées, shell_exec() permet d’utiliser la commande crontab.
Or, crontab permet de définir des tâches cron (je vous renvoie à Google si vous ne savez pas ce que c’est : cron est un gestionnaire de tâches planifiées). Or, quand cron lance la tâche, qu’elle qu’elle soit, elle est lancée au niveau de l’utilisateur auquel le cron appartient.
Concrètement si je fais ceci :
file_put_contents('temp.cron', '* * * * * cp /chemin/dun/autre/site/includes/passwordsdatabase.inc.php /chemin/de/mon/site/');
shell_exec('crontab -u dtc /chemin/de/mon/site/temp.cron');
Hop, plus qu’à attendre une minute et j’aurais dans mes fichiers… les mots de passe de la base de données de mon voisin sur le serveur.
C’est un problème très important, donc, et je ne sais pas du tout comment DTC compte gérer les choses dans le futur puisque le safe_mode est amené à disparaîre : déjà considéré comme obsolète dans PHP 5, il sera définitivement supprimé avec PHP 6.
Il est possible que – comme souvent en informatique – GPLHost (éditeur de DTC) dise simplement « Logiciel compatible uniquement avec les versions suivantes de PHP : …. ».
En attendant, vous êtes donc maintenant au courant : NE DESACTIVEZ PAS LE SAFE_MODE PHP SI VOUS UTILISEZ DTC AVEC PLUSIEURS SITES DIFFERENTS.
Cependant, il y a certainement une alternative à cela : j’imagine bien que PHP ou Apache ont la possibilité d’interdire certaines commandes. Ainsi lorsque vous désactivez le safe_mode, pensez à interdire l’utilisation de la commande shell_exec().
Voilà c’était le bulletin sécurité (en exclu !!) du Troll
Poster un commentaire