www-data l'utilisateur malicieux

Eléphant du PHP | 153 Messages

06 mai 2006, 08:45

Bonjour !

J'ai un serveur Linux (Debian), avec installé dessus Apache 2, PHP 5 et tout le reste nécessaire au bon fonctionnement d'un site web.

J'ai créé plusieurs utilisateurs dans un même groupe (j'ai appelé ce groupe "webuser"). Ces membres ne peuvent pas voir le contenu des autres membres du même groupe (chmod 707 sur tout leurs dossiers et fichiers).

Je ne sais pas si jusque là j'ai fait une bonne configuration, mais ça avait l'air de tenir la route.

Malheureusement, il existe un moyen pour passer au travers de cette protection, et quand même aller voir les contenus des autres utilisateurs.
Et c'est là où arrive l'utilisateur www-data.

Pour ceux qui ne le connaisse pas, www-data est un utilisateur créé par Apache dans le but de lire et exécuter les pages web se trouvant sur un serveur (les données pour le web (www-data) ;)).
Or, www-data fait parti (sur mon serveur) du groupe "autre" dans le chmod des dossiers et donc il peut tout faire dans les répertoires de chaque utilisateur.
Avec un peu de php malicieux, il est donc possible de récupérer les mots de passe ou détruire le contenu d'un autre membre... Bref, que des choses non souhaitées.

Je voudrais donc savoir comment peut-on résoudre ce problème. Je me suis tourné vers le système des "jails", mais cette méthode ne me semble pas être la bonne (à cause du volume supplémentaire pris sur le disque). J'ai aussi pensé aux ACL, mais le problème serait toujours le même, il me semble, www-data devra avoir l'accès aux fichiers et la faille sera toujours là.

Les hébergements professionnels (j'ai juste regardé sur ovh) ont contourner ce problème. Comment ont-ils fait ?!

Merci à tous :)
http://gl2.delcedo.com/ Galaxialord 2 !

Mammouth du PHP | 19672 Messages

06 mai 2006, 08:55

Ça, c'est de le gestion de serveur : sujet déménagé.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse :axe:

Eléphant du PHP | 153 Messages

06 mai 2006, 08:58

Désolé, c'est le matin et j'avais pas les yeux en face des trous :oops:
http://gl2.delcedo.com/ Galaxialord 2 !

Administrateur PHPfrance
Administrateur PHPfrance | 3131 Messages

06 mai 2006, 11:32

C'est le rôles des options open_basedir et safe_mode du php.ini que de résoudre ces failles.

Eléphant du PHP | 153 Messages

06 mai 2006, 13:24

Je viens d'étudier ce qu'était l'open_basedir.

Cela ne résoud pas mon problème et de plus je ne sais pas si on peut avoir un php.ini pour chaque utilisateur.

Je vais expliquer plus clairement mon problème avec un script en exemple :
<pre><?php
system("ls -l /");
echo "<hr />";
system("cat ../../autreUtilisateur/public_html/motDePass.php");
?>
</pre>
Ce script fonctionnera et affichera bien les résultats des commandes systèmes. Comment empêcher à php (ou www-data) d'aller voir autre part que le dossier de l'utilisateur ? (et supprimer la fonction system() n'est pas une solution).

Merci :)
http://gl2.delcedo.com/ Galaxialord 2 !

ViPHP
ViPHP | 1380 Messages

06 mai 2006, 13:36

Je voudrais donc savoir comment peut-on résoudre ce problème. Je me suis tourné vers le système des "jails", mais cette méthode ne me semble pas être la bonne (à cause du volume supplémentaire pris sur le disque). J'ai aussi pensé aux ACL, mais le problème serait toujours le même, il me semble, www-data devra avoir l'accès aux fichiers et la faille sera toujours là.

Les hébergements professionnels (j'ai juste regardé sur ovh) ont contourner ce problème. Comment ont-ils fait ?!
Commence par open_basedir comme suggéré par Naholyr. Il y a cependant un bug dans l'implémentation de CURL dans certaines versions de PHP qui permet de passer au travers de l'open_basedir.

[parano]
Les spécilalistes de la sécurité chroot(ent) l'installation d'Apache pour palier ce genre de faille.

Quant à la place disque du chroot, tu n'es pas obligé de tout y mettre. Seules les commandes utilisées par Apache.

Il me semble qu'Ivan Ristic (mod_security) a écrit un utilitaire pour chrooter Apache de manière simple.

Un petit coup de :google: "chroot apache" devrait te donner des pistes.
[/parano]
ripat

Eléphant du PHP | 153 Messages

07 mai 2006, 23:16

safe_mode = Off

Le mettre à On me permet de résoudre le problème, mais il le résoud un peu trop de manière "bourrine". En effet, les fonctions system() et exec() (et leurs dérivées) ne donnent plus rien (et donc la dernière ligne de mon code ci-dessous ne marche pas).

Sinon j'ai bien essayé avec open_basedir mais cela n'empeche pas ce script de fonctionner comme il ne devrait pas :
<pre><?php 
system("ls -l /"); // ne devrait rien afficher
echo "<hr />"; 
system("cat ../../autreUtilisateur/public_html/motDePass.php"); // la non plus
echo "<hr />";
system("ls -l"); // seule opération qui devrait fonctionner
?> 
</pre>
http://gl2.delcedo.com/ Galaxialord 2 !

ViPHP
ViPHP | 1380 Messages

08 mai 2006, 21:32

Et bien, mon pauvre vieux, il va donc te falloir chrooter Apache si tu veux garder exec() passthru() et toute la famille.
:wink:

(Ce n'est pas la mer à boire, regarde les infos de mon post plus haut)
ripat

Eléphant du PHP | 153 Messages

09 mai 2006, 15:15

:( si je suis obligé de faire cette méthode je la ferai... mais bon j'aurai préféré un truc plus simple :oops: Disons que je maîtrise moyennement linux :cry:

Pourtant ca serait génial s'il pouvait faire juste la vérification de l'uid et terminé, pas besoin de tout le reste du safe_mode....

Bon j'attends la fin du mois et s'il y a pas d'autres solutions je ferai du chrootage :(

(dsl pour l'autre post (supprimez le svp :oops: ) et l'utf8, opera a quelques problèmes encore avec la reconnaissance de l'encodage)
http://gl2.delcedo.com/ Galaxialord 2 !

Petit nouveau ! | 3 Messages

16 juin 2006, 18:24

tu peux rajouter un truc comme ça dans ta config de virtual host :

Code : Tout sélectionner

<IfModule mod_php5.c> php_admin_value open_basedir "/var/www/client:/tmp" </IfModule>
au moins une config de open_basedir par client :)