Dans un contexte PHP / Apache / Linux, pourquoi chmod 777 est-il dangereux?
inspiré par la discussion dans cette question , une question peut-être stupide.
Nous avons appris que laisser des répertoires ou des fichiers sur Linux hébergement web avec le niveau d'autorisation de 777 est une mauvaise chose, et toujours aussi peu les autorisations nécessaires.
je suis maintenant curieux de savoir où exactement se trouve le danger d'exploitation, spécifiquement dans un contexte PHP / Apache.
après tout, un fichier de script PHP peut être exécuté de l'extérieur (c'est-à-dire par un appel au serveur web, et par la suite à l'interpréteur) peu importe qu'il soit marqué comme "exécutable", n'est-ce pas? Et la même chose s'applique aux fichiers appelés par l'intermédiaire de l'interpréteur en ligne de commande php , n'est-ce pas?
alors où est exactement la vulnérabilité avec 777 ? Est-ce le fait que les autres utilisateurs sur le même machine peut accéder aux fichiers qui sont rendus World writable?
4 réponses
voici un scénario:
- Vous avez un répertoire non protégé que les utilisateurs peuvent télécharger.
- télécharger deux fichiers: un script shell, et un fichier php qui a une
system()appel au script shell. - ils accèdent au script php qu'ils viennent de télécharger en visitant l'url de leur navigateur, provoquant l'exécution du script shell.
si ce répertoire est 777, cela signifie que n'importe qui (y compris l'utilisateur apache, qui est ce que le script php exécutera sous) peut l'exécuter! Si le bit d'exécution n'est pas défini sur ce répertoire et probablement les fichiers à l'intérieur du répertoire, alors l'étape 3 ci-dessus ne ferait rien.
éditer à partir des commentaires: Ce n'est pas les permissions du fichier PHP qui importe, c'est l'appel system() à l'intérieur du fichier PHP qui sera exécuté comme un appel système linux par l'utilisateur linux apache (ou ce que vous avez apache défini pour exécuter en tant que), et c'est PRÉCISÉMENT là où le bit d'exécution questions.
il y a beaucoup de bonnes raisons générales de suivre le Minimalisme quand il s'agit de permissions, mais dans le contexte D'un hébergeur de lampes, les quelques qui viennent facilement à l'esprit sont
- sur une plate-forme d'hébergement partagée, les autres utilisateurs partageant votre hôte peuvent maintenant lire et écrire à vos scripts.
- sur un hôte dédié, les processus rouge peuvent lire/écrire et supprimer accidentellement vos fichiers. Disons qu'il y a un processus de journalisation personnalisé background as user nobody qui a un bug qui en résulte en essayant de
rm -rf /. Maintenant, généralement ce sera inoffensif parce qu'il y aurait à peine n'importe quel dossier que personne ne devrait avoir les permissions d'écriture sur mais ce processus rouge va maintenant prendre vos dossiers avec elle. - pour défigurer votre site web, quelqu'un doit seulement obtenir l'accès que tout utilisateur, même dire personne ou un tel compte fictif. Généralement, l'attaquant devrait faire une nouvelle attaque d'escalade au niveau de l'utilisateur pour se rendre à l'endroit où il peut faire des dégâts. C'est une menace réelle. Certains services non essentiels peuvent fonctionner sous des comptes fictifs et contenir une vulnérabilité.
il augmente considérablement le profil de vulnérabilité de votre site web à des activités malveillantes, car il est seulement nécessaire de casser dans un compte.
N'importe qui qui gagne l'accès à votre système avec n'importe quel login peut faire ce qu'ils veulent à vos pages, y compris les changer pour lire "ce site web est vraiment peu sûr donc s'il vous plaît donnez-moi votre information de carte de crédit."
EDIT: (à préciser et À l'adresse de commentaires)
beaucoup de serveurs ont plus d'un but dans la vie. Ils gèrent plusieurs services. Si vous isolez soigneusement ces services les uns des autres en assignant à chacun un utilisateur unique et en gérant les permissions de fichiers en conséquence, oui, vous êtes toujours dans l'eau chaude si quelqu'un compromet les informations d'identification pour un compte, mais le dommage qu'ils peuvent faire est limité à ce service. Si vous n'avez qu'un seul compte générique et que vous mettez tout le système de fichiers à 777, un seul compte compromis met tout en péril sur la machine.
si votre serveur est dédié à L'exécution D'Apache/PHP et ne sert à rien d'autre dans la vie, et qu'il n'y a qu'un seul compte sous lequel Apache/PHP est exécuté, le fait d'avoir ce compte compromis est aussi bon que d'avoir toute la machine compromise du point de vue de votre application (bien que vous devriez toujours avoir des fichiers système protégés et non accessibles en écriture par le compte utilisé pour exécuter PHP... cela ne devrait être possible que pour un compte administrateur/root).
S'ils peuvent écrire un fichier, et qu'il est exécutable, ils peuvent le changer en quelque chose qui s'exécute sur votre machine (exécutable ou script) et ensuite utiliser le shell_exec de PHP pour exécuter cet exécutable. Si vous êtes configuré pour ne pas autoriser shell_exec, ils peuvent aussi modifier votre configuration
supposons que vous ayez un paquet de logiciel installé sur votre serveur et qu'il y ait une vulnérabilité de jour zéro, l'attaquant accède à votre Panneau de contrôle Admin avec des capacités de téléchargement de fichiers, si vous réglez tout sur 777 il serait trivial pour lui de télécharger un script shell n'importe où il veut. Cependant, si vous définissez les permissions correctement, il ne peut pas le faire puisque personne/www-data/etc n'aura de permissions d'écriture.