Dans un PHP / Apache/Linux, pourquoi chmod 777 est-il dangereux?
Inspiré par la discussion dans cette question , une question peut-être stupide.
Nous avons tous appris que laisser des répertoires ou des fichiers sur un hébergement Web sous Linux avec le niveau d'autorisation 777 était une mauvaise chose et qu'il fallait toujours définir le moins d'autorisations possible.
Je suis maintenant curieux de savoir où se trouve exactement le danger d’exploitation, en particulier dans un contexte PHP/Apache.
Après tout, un fichier de script PHP peut être exécuté de l'extérieur (c.-à-d. Via un appel au serveur Web, puis à l'interpréteur), qu'il soit marqué ou non comme "exécutable". ? Et il en va de même pour les fichiers appelés via l'interprète php en ligne de commande, n'est-ce pas?
Alors, où est exactement la vulnérabilité avec 777? Est-ce le fait que d'autres utilisateurs sur le même ordinateur peuvent accéder à des fichiers accessibles en écriture au monde?
Voici un scénario:
- Vous avez un répertoire non protégé que les utilisateurs peuvent télécharger.
- Ils télécharger deux fichiers: un script Shell, et un fichier php qui a un appel en
system()au Shell script. - ils accèdent au script php qu'ils viennent de télécharger en visitant l'URL de leur navigateur, ce qui provoque l'exécution du script Shell.
Si ce répertoire est 777, cela signifie que tout le monde (y compris l'utilisateur Apache, qui est ce que le script php exécutera comme) peut l'exécuter! Si le bit d'exécution n'est pas défini sur ce répertoire et vraisemblablement sur les fichiers qu'il contient, alors l'étape 3 ci-dessus ne ferait rien.
modifier à partir des commentaires: ce ne sont pas les autorisations du fichier PHP qui importent, mais l'appel system() dans le fichier PHP qui sera exécuté en tant qu'appel système Linux par l'utilisateur Apache (ou quel que soit le type d’Apache sur lequel exécuter), c’est PRÉCISEMMENT l’importance du bit d’exécution.
Cela augmente considérablement le profil de vulnérabilité de votre site Web en ce qui concerne les activités malveillantes, car il suffit de vous connecter à un seul compte.
Toute personne qui accède à votre système avec n'importe quel identifiant peut faire ce qu'elle veut sur vos pages, y compris en les modifiant comme suit: "Ce site Web est vraiment peu sécurisé, donnez-moi s'il vous plaît vos informations de carte de crédit."
EDIT: (pour clarifier et répondre aux commentaires)
De nombreux serveurs ont plusieurs objectifs dans la vie. Ils courent plusieurs services. Si vous isolez soigneusement ces services les uns des autres en attribuant à chacun un utilisateur unique et en gérant les autorisations de fichiers en conséquence, vous êtes toujours dans le pétrin si quelqu'un compromet les informations d'identification d'un compte, mais les dommages qu'il peut causer sont limités à ce service . Si vous ne possédez qu'un seul compte générique et que vous définissez l'ensemble du système de fichiers sur 777, un compte compromis met tout en péril sur la machine.
Si votre serveur est uniquement dédié à l'exécution d'Apache/PHP et ne sert à rien d'autre, et s'il n'y a qu'un seul compte sous lequel Apache/PHP est exécuté, le fait de compromettre ce compte revient à faire en sorte que la machine entière soit compromise depuis le système d'exploitation. point de vue de votre application (bien que vous devriez toujours avoir des fichiers système protégés et non-inscriptibles par le compte utilisé pour exécuter PHP ... cela ne devrait toujours être possible que pour un compte/une racine administrateur).
S'ils peuvent écrire un fichier et qu'il est exécutable, ils peuvent le remplacer par un élément qui s'exécute sur votre ordinateur (exécutable ou script), puis utiliser Shell_exec de PHP pour exécuter cet exécutable. Si vous êtes configuré pour ne pas autoriser Shell_exec, ils peuvent également modifier votre configuration.
Il existe de nombreuses bonnes raisons générales de suivre le minimalisme en matière d’autorisations, mais dans le contexte d’un hébergeur LAMP, les quelques idées qui vous viennent immédiatement à l’esprit sont les suivantes:
- Sur une plate-forme d'hébergement partagé, les autres utilisateurs partageant votre hôte peuvent désormais lire et écrire dans vos scripts.
- Sur un hôte dédié, les processus rouge peuvent lire/écrire et supprimer accidentellement vos fichiers. Disons qu'un processus de journalisation personnalisé s'exécute en arrière-plan en tant qu'utilisateur nobody et qu'un bogue entraîne sa tentative de
rm -rf /. Désormais, cela sera généralement sans danger, car il n’y aurait pratiquement aucun fichier sur lequel personne ne devrait avoir d’autorisation d’écriture, mais ce processus va maintenant prendre vos fichiers avec lui. - Pour altérer votre site Web, il suffit que quelqu'un, y compris personne ou un compte fictif, y ait accès. En règle générale, l'attaquant doit effectuer une autre attaque avec escalade au niveau utilisateur pour se rendre à l'endroit où il peut causer des dommages. C'est une vraie menace. Certains services non critiques peuvent s'exécuter sous des comptes factices et peuvent contenir une vulnérabilité.
Supposons qu'un logiciel installé sur votre serveur comporte une vulnérabilité de jour zéro, que l'attaquant puisse accéder à votre Panneau de configuration Admin avec la fonctionnalité de téléchargement de fichiers, si vous définissez le tout sur 777, il serait facile pour lui de télécharger une Script Shell où il veut. Cependant, si vous définissez correctement les autorisations, il ne pourra pas le faire car personne/www-data/etc ne disposera d'aucune autorisation en écriture.