suPHP = sécurité ??
8 réponses
| Auteur | Message |
|---|---|
|
Akarys
| 
Inscrit le : 19/01/2008 |
# Le 30/11/2008 à 08:29 Bonjour, Bool a dit :(...) Après pour l'aspect sécurité, le suPHP pour moi sert surtout à limiter l'étendu des dégats en cas de faille dans un site : c'est déjà assez "chiant" qu'un pirate infiltre un site, je n'ai pas spécialement envie qu'il se propage sur tous les sites de la machine. (...) Là il y a un truc qui m'échappe  Pour moi le seul intérêt de suPHP est d'éviter que les users s'espionnent mutuellement quand on a plusieurs users sur un serveur, surement pas d'augmenter la sécurité du serveur. Si un pirate trouve une faille sur le site de user1, il va au contraire pouvoir télécharger du code dans le compte de user1 et, même s'il est en théorie limité à l'Espace de user1 va pouvoir exécuter du php sur ton serveur ! Pas glop  S'il trouve une faille sur une config sans suPHP il va se retrouver nobody ou www-data et n'aura PAS possibilité d'écrire sur le serveur pour y modifier tes sources ou placer ses fichier ou du code accessibles du web. Dans tous les cas il peut y avoir moyen d'exécuter du code distant s'il y a des include() mal protégés, mais là encore je préfère qu'il soit nobody. Que peut-il me faire de mal ? Au pire lire les sources des autres domaines ? Oui, mais est-ce aussi grave que de pouvoir écrire sur le serveur ? Suis-je depuis des années passé à côté d'un point important ? (sachant que je suis seul sur mes serveurs) |
|
Bool
| Olivier 
Inscrit le : 09/05/2005 |
# Le 30/11/2008 à 15:00 Bonjour, Si un pirate trouve une faille sur le site de user1, il va au contraire pouvoir télécharger du code dans le compte de user1 et, même s'il est en théorie limité à l'Espace de user1 va pouvoir exécuter du php sur ton serveur ! Oui, exactement comme avec modPHP non ? S'il trouve une faille sur une config sans suPHP il va se retrouver nobody ou www-data et n'aura PAS possibilité d'écrire sur le serveur pour y modifier tes sources ou placer ses fichier ou du code accessibles du web. Il en est de même avec suExec, mais effectivement à priori pas avec suPHP : suPHP fait tourner PHP sous le même user que le proprio des scripts, ce qui est effectivement peu prudent (on offre ainsi au pirate l'accès en écriture). Mais là c'est plus un problème de configuration qu'autre chose je dirais : avec modPHP on peut avoir exactement le même problème si les scripts sont créés sous www-data/nobody. Avec suExec j'utilise généralement 2 comptes par site, un compte propriétaire des fichiers, et un compte d'exécution. Dans tous les cas il peut y avoir moyen d'exécuter du code distant s'il y a des include() mal protégés, mais là encore je préfère qu'il soit nobody. Que peut-il me faire de mal ? Au pire lire les sources des autres domaines ? Oui, mais est-ce aussi grave que de pouvoir écrire sur le serveur ? "nobody"/"www-data" n'est qu'un compte comme les autres... avec quand même l'énorme avantage d'avoir le droit de lire tous les fichiers/scripts relatifs à tous les sites. Je prends le cas d'un serveur avec un seul site, et un "vieux" phpMyAdmin qui aurait une faille de sécurité quelconque. Avec modPHP, les scripts du site ainsi que phpMyAdmin tournent sous le même compte utilisateur, et ont donc les mêmes droits d'accès aux fichiers, les deux seules pseudo sécurités(1) sont le SAFE_MODE et l'OPEN_BASEDIR que beaucoup désactivent ne sachant pas s'en servir. Dans ce cas, le pirate depuis une faille dans phpMyAdmin peut parfaitement aller lire le fichier "dbconfig.php" de ton site, et ainsi obtenir tes identifiants MySQL (voir FTP pour les malins qui utilisent les mêmes login/pass pour tout). Avec suPHP (normalement hein, je ne l'utilise pas, lui préférant suExec), chaque "script" sera isolé sous un compte unix différent. Ainsi une faille dans phpMyAdmin ne concernera que phpMyAdmin... au mieux le pirate aura accès aux fichiers du système qui sont en lecture à tout le monde, c'est à dire les fichiers sans importance (enfin normalement). Et suExec est justement quelque chose de relativement "blindé", qui n'est pas du tout spécifique à PHP ; il y a peu de chance qu'on puisse exploiter une éventuelle faille de ce coté. Par contre il est vrai que la configuration est plus complexe, et qu'il faut évidement que le système derrière ne soit pas configuré n'importe comment : si tous les utilisateurs ont le droit de lire les fichiers de tout le monde, le problème reste le même... De plus avec PHP 6 le standard sera clairement suExec vu que ces pseudos sécuritées seront complètement supprimées. Autant s'y habituer dès maintenant. 1 - "pseudos sécurités" car théoriquement non fiable à 100%. Rasmus Lerdorf les compare à des préservatifs persés... |
|
petitnuage
| Sam Inscrit le : 20/11/2008 |
# Le 30/11/2008 à 18:26
Akarys a dit : Pour moi le seul intérêt de suPHP est d'éviter que les users s'espionnent mutuellement quand on a plusieurs users sur un serveur, surement pas d'augmenter la sécurité du serveur. Pas mal de gens stockent des mots de passes dans du code PHP notamment. A partir de là, il suffit d'avoir l'accès en lecture sur ces fichiers pour obtenir ces mots de passe. Si tu es en suPHP, les seuls mots de passe que le pirate pourra dérober concernent ceux stockés chez l'utilisateur piraté. Les mots de passe concernent l'accès à la BDD ou l'accès à un FTP distant, par exemple, auquel se connectent les scripts PHP. De plus, de nombreux CMS proposent des installations automatisées qui génèrent leurs propres configurations dans des fichiers PHP. Du coup, prendre le contrôle d'un seul utilisateur nobody/www-data permet de fait de prendre le contrôle de tous les sites hébergés, et pas juste les sites d'un utilisateur en particulier. En d'autres termes, avoir un site sécurisé ne permet pas de s'assurer que celui-ci ne sera pas piraté avec un utilisateur unique nobody/www-data pour l'exécution PHP, alors que l'utilisation de suPHP permet d'éviter ce risque. |
|
Akarys
| Thierry
Inscrit le : 19/01/2008 |
# Le 01/12/2008 à 05:52 Bonjour, |
|
Bool
| Olivier
Inscrit le : 09/05/2005 |
# Le 01/12/2008 à 06:22
Euh... J'ai aussi vu des serveurs avec du 777 sur tous les répertoires, et même un apache tournant sur le user root au lieu de nobody (!), mais je parlais ici d'une config Debian en prod, pas du newbie sur son PC en local Ouais tout est relatif ici... j'ai vu pas mal de serveurs avec ce type de config, voir même sans le couple safe_mode/open_basedir. J'ai récemment eu un client dont les devs avaient donnés tous les droits "sudo" à l'utilisateur www-data pour ne pas avoir à s'embêter avec les droits d'accès aux fichiers... et c'était en prod depuis des années... Moi même j'ai des installations pas forcément super cleans selons les besoins du client ; certains se contrefichent de l'aspect sécurité, et le moindre "chmod" nécessaire sur un dossier est considéré comme chiant. Sauf erreur il n'y a plus de mots de passes de stockés en clair dans les fichiers php de phpMyAdmin depuis des années... 1 - je parlais du fichier de configuration de ton site, qui a quasi obligatoirement un fichier de ce genre, et qui est lisible par l'utilisateur www-data/nobody 2 - le mot de passe de la connexion "control" de phpmyadmin est toujours en clair dans le fichier de conf, et parfaitement accessible peu importe la configuration de PHP Encore une fois je vois mal comme tu peux "prendre le contrôle" d'un site quand tu n'a pas accès en écriture... Injection de code dans un eval(), upload d'un script à la place d'une image, include() trop permissif. Et ça, c'est juste pour forcer l'exécution d'un code arbitraire. Après il y a des bétises plus fréquentes telles que le readfile() sans vérification, qui permet au pirate de récupérer n'importe quel fichier auquel ton script PHP a un accès en lecture... dont les scripts contenant les identifiants d'accès au serveur MySQL. Et il y a sûrement d'autres méthodes du genre, le fait d'utiliser PHP en module ou via suexec n'y changera absolument rien. Ce qui change c'est que le pirate soit limité à un seul site/appli (suexec fonctionne par virtualhost). Pour ce qui est de deviner le chemin d'accès aux fichiers, demande à M freeheberg ce que ça donne  Un bête script pour parcourir l'arborescence du serveur à ta guise, et c'est magique tu chopes tout ce que tu veux. |
|
Akarys
| Thierry
Inscrit le : 19/01/2008 |
# Le 01/12/2008 à 07:21
Sauf erreur il n'y a plus de mots de passes de stockés en clair dans les fichiers php de phpMyAdmin depuis des années... 2 - le mot de passe de la connexion "control" de phpmyadmin est toujours en clair dans le fichier de conf, et parfaitement accessible peu importe la configuration de PHP Euh... Il faut que je regarde la doc. Je pensais ne pas être concerné par ce "control". D'ailleurs dans ma conf je trouve : $cfg['Servers'][$i]['controluser'] = ''; $cfg['Servers'][$i]['controlpass'] = ''; C'est grave docteur ? Pour ce qui est de deviner le chemin d'accès aux fichiers, demande à M freeheberg ce que ça donne Un bête script pour parcourir l'arborescence du serveur à ta guise, et c'est magique tu chopes tout ce que tu veux.Pour parcourir l'arborescence il faut avoir accès en lecture aux répertoires, et il n'y a aucune raison valable de laisser ce droit à nobody/www-data. |
|
Bool
| Olivier
Inscrit le : 09/05/2005 |
# Le 01/12/2008 à 07:33 La connexion "control" sert à phpMyAdmin pour le stockage des bookmarks, et autres fonctions "avancées" de phpMyAdmin. Mais si tu ne les utilises pas, tu n'as évidement pas besoin de la dite connexion. Pour parcourir l'arborescence il faut avoir accès en lecture aux répertoires, et il n'y a aucune raison valable de laisser ce droit à nobody/www-data. Alors là tu m'indrigues : comment empêches-tu cela ? EDIT : trouvé, avec les droits 711 sur le répertoire... punaise merci ! |
|
Akarys
| Thierry
Inscrit le : 19/01/2008 |
# Le 15/12/2008 à 05:52
Bool a dit :EDIT : trouvé, avec les droits 711 sur le répertoire... punaise merci !Gagné Bool  , voire même 710 ou 701 suivant ta configuration.Il est bien dommage que tous les exemples et tutoriels ne jurent que par 755, certes c'est plus facile, mais aussi au combien plus dangereux... Le "punaise" de ta réponse laisse penser que tu ne connaissais pas cette possibilité, et je peux te dire que tu es loin d'être le seul... Tu comprends maintenant ce que je voulais dire par "il te faudra d'abord deviner le nom et le path d'accès complet à ces fichiers" ...  |
|
Bool
| Olivier
Inscrit le : 09/05/2005 |
# Le 15/12/2008 à 11:33 Yep yep, complètement, jamais vu ça en cours, dans les bouquins, ou sur le net... c'est quand même con. |
Répondre
Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.